HDTenEightyP/NetNews huggingface dataset:
From: bf4grjc@SOCRATES.MIT.EDU (Ganesan)
Subject: Re: NTP mailing list?
Reply-To: bf4grjc@socrates.bell-atl.com
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 12 Nov 1992 15:56:59 GMT

> 
> I can add you to the mailing list.

Thanks, Could you add bbh7rqj@socrates.bell-atl.com to the list? This is 
not me, but a colleague (Chris Davies), who is monitoring NTp more closely.

> 
> There is no FAQ that I know of, though you may want to grab the file
> /pub/ntp/clock.txt from LOUIE.UDEL.EDU.
> 
Will do.

> I don't know what you mean about an NTP that works with Kerberos.  NTP
> uses its own authentication mechanism.  Using Kerberos is not really
> appropriate for a number of reasons, the most troublesome of which is
> that kerberos relies on loosely synchronized clocks, which is what NTP
> is trying to do.
> 
We use the current authentication scheme available with NTP, and realize 
that the notion of the security of the  time service relying on the 
security of the security service which relies on the security of the 
time service is troubling! However, in the absence of any name/time/security
services designed together in a secure fashion, we feel it is probably 
easier (administratively speaking) to have a single security mechanism (in 
this case Kerberos).

Thanks,

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: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
Subject: Re: problem with kpasswd
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 6 Nov 1992 21:55:41 GMT


   Date: Fri, 6 Nov 92 15:11:33 CST
   From: yuan@syl.dl.nec.com	(Ruixi Yuan)

   Unable to Get Initial Credentials : Server not found in Kerberos database

You need to create the principal "kadmin/REALM".

If you apply the kdc patch I posted and look at the logged error
message you will see that this is the principal that kpasswd is
requesting a servicee ticket for.

Barry Jaspan
Newsgroups: comp.protocols.kerberos
From: jmcarli@srv.PacBell.COM (Jerry M. Carlin)
Subject: missing key_perm.h (K5v2)
Keywords: Kerberos5 V2
Organization: Pacific * Bell
Date: Wed, 11 Nov 1992 20:47:33 GMT


I've got a 'make world' error:

	...
	including in tests/hammer...
	including in ./config-files...
	make: Fatal error: Don't know how to make target `key_perm.h'
	Current working directory /tools/src/k/kerberos5/v2/src
	*** Error code 1
	make: Fatal error: Command failed for target `world'

A find shows it's not in the V2 tree but I did find it in the K5 beta 1
distribution (v1/src/lib/des/key_perm.h).  Copying it to the corresponding
place in beta2 (and to the config-files directory) and doing a new 'make
world' did not solve the problem.

Any hints? 
-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist
Newsgroups: comp.protocols.kerberos
From: mit-eddie!harvard!scubed!flamingo.SanDiego.NCR.COM!donnh
Subject: safe message problem: HP to 486
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 00:07:44 GMT


This is probably old news but here goes ...

We're trying to inteoperate between our i486 machine running a port of
Kerberos 4.9 and an HP-9000 system running version 4.? (don't know the
exact version). When receiving "safe" messages sent by the HP
system, we fail comparing the checksums and reject the message. 

The 4.9 source tries to account for the different machine
architectures by invoking swap_u_16() on one of the checksums before
comparing the received checksum with that generated by des_quad_cksum
on our side.  However, swap_u_16() swaps the ENTIRE 16 bytes as
follows:
   original bytes: 000102030405060708090a0b0c0d0e0f
   after swap:     0f0e0d0c0b0a09080706050403020100

Unfortunately des_quad checksum() on the 486 returns:
				   03020100070605040b0a09080f0d0e0c
If one swaps the bytes in EACH long independently you get:
				   000102030405060708090a0b0c0d0e0f
Which is the same value as the checksum sent in the message!

It looks like the call to swap_u_16() should be changed to 4 calls to
swap_u_long(), or swap_u_16() be changed to handle swapping within the
long integers that make up the checksum. Alternatively swapping could
be removed from rd_safe and des_quad_checksum changed to create a
machine independent 16 or 32 byte value.

If this is a known bug is there a standard fix? I also assume that
private message handling is impacted, but I haven't looked into it
yet.

By the way the machine definitions for the 486 are:

#define BITS32
#define BIG
#define LSBFIRST

Any help would be appreciated.

Thanks in advance.

-- 
Donn Holtzman					Donn.Holtzman@SanDiegoCA.NCR.COM
NCR LCPD-San Diego, MS 1240
16550 W. Bernardo Drive
San Diego, CA 92127

Telephone: (619)485-3396		FAX: (619)485-2598
VoicePlus: 440-3396
Newsgroups: comp.protocols.kerberos
From: mqh@LEMUR.CIT.CORNELL.EDU (Mike Hojnowski)
Subject: Re: The incredible missing Principle trick
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 13 Nov 1992 14:08:30 GMT


>One possible reason is that you got unlucky with a hash collision which
>caused the DBM file to grow bigger than the max. allowable filesize on
>your system, and you have a badly implemented DBM library that doesn't
>deal well with that situation (i.e., fails silently) --- but that's only
>a guess.  At MIT, we haven't had that problem happen with our Kerberos
>database, which has almost 20,000 entries in it.  However, we have had
>this sort of problem with our /usr/lib/aliases file on our mailhub,
>when the length of the /usr/lib/aliases.pag gets bigger than 2
>gigabytes.

>I'm not sure I believe this is what's really happening, though, since
>6,000 principals isn't all that many.  We haven't seen your problem at
>MIT, although we're not running our server on a RS/6000.

Ted,  Thanks for the idea.  I don't think that's it either.  Our principal.pag
is only about 98M.  I've got a call into IBM to see if anyone's reported 
DBM bugs on AIX 3.  I'm also going to check my error logs on the off chance
there was actually a disk error reported somewhere.

Thanks again,

Mike
From: smb@ulysses.att.com
Newsgroups: comp.protocols.kerberos
Subject: Re: Local password validation (was: kerberizing xlock)
Date: 5 Nov 92 08:08:49 GMT
Organization: Internet-USENET Gateway at Stanford University


	 OK,  now  I  see what  your  getting  at,  and  I  agree  that  it  is
	 theoretically possible  to accomlish  this.   I think that V  could be
	 designed  and  located on the  network in such  a way as to  make this
	 attact extremely difficult, if not impossible

Anyone who thinks that active spoofing of a server is impossible or
even prohibitively difficult should read ``A Unix Network Protocol
Security Study: Network Information Service'', by Hess, Safford, and
Pooch, in the October '92 (vol 22, no 5) issue of Computer
Communications Review.


		--Steve Bellovin
Newsgroups: comp.protocols.kerberos
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Prelease testers for a final distribution of Kerberos V4
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 11 Nov 1992 23:01:32 GMT

I am preparing a "final" Kerberos V4 release by MIT.  The primary new
features include:  enhancements to the kadmin server to enforce password
quality, a kadmind support and a new kamdind client to do remote srvtab
generation, and a lot of porting changes to make Kerberos V4 compile on
platforms such as the Sun, RS/6000, sgi, irix, and the HP.  Since I am
not in a position to test all of the porting changes, I am looking for a
few prerelease testers to try it out and let me know of any problems.

If you are interested, please send mail to me.  The pre-release will go
out on Friday, and I'd like the pre-release testers to try it and get
back to me within a week.  If you don't have time to look at it right
away, then just wait, since the final version will be coming out a week
from now anyway (i.e., the week after the IETF meeting).  I am
especially interested in people who have access to the above platforms
and who are willing to try compiling Kerberos V4 on them.

This release will represent the final Kerberos V4 release that we expect
to do at MIT.  Its main motiviation is the fact that several parties
have obtained copies of our internal source tree, which has several new
features and supports additional platforms that are not in the publicly
released V4 distribution.  Thus, we are making a final release so that
everybody can have equal access to our code.

We are not planning on doing any further Kerberos V4 work at this time;
our future development efforts will be based off of Kerberos V5, not V4.

							- Ted
Newsgroups: comp.protocols.kerberos
From: pato@APOLLO.HP.COM (Joe Pato)
Subject: Re: Local password validation (was: kerberizing xlock)
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 6 Nov 1992 18:36:27 GMT


    Also, there is no need to actually contact the local verification
    service out of band.  The verification can be done entirely by the
    login program.  
    
    What you would do is initially request a ticket for the verification
    service, use that ticket to construct an authenticator, then
    immediately verify the ticket and authenticator from within the login
    program using the "local verification" services key which is
    presumably available to the login program since it runs as root.
    
    You could simplify this even further if you were willing to write your
    own code to do the verification, instead of using the code in the
    Kerberos library.  To do this, you would:
    
The OSF DCE Security library, leveraging Kerberos V5) provides this capability.
The sec_login_validate_and_cert_ident will both validate the user's password
(and obtain the user's TGT) and certify that the KDC is legitimate.   It
obtains a ticket to the local machine principal and verifies that the KDC
shares a key with the machine.  This call must be made by a privileged process
that has access to the machine principal's key (the system login code
qualifies)  Unprivileged processes may make a simillar call that communicates
with a local privileged service that has access to the local machine
principal's key.

An unprivileged call sec_login_validate_identity exists for applications that
do not care to certify the KDC.

This approach for local authentication validation is not weaker[1] than
conventional local authentication.  In any case the mechanism requires the
local machine to be resistent to attack.  In this model, the local machine
principal's key must be protected, in the conventional unix case the
/etc/passwd file must be protected from modification.  In either case breaking
local protections will compromise the authentication path.

[1] Using the network KDC for user authentication is weaker than a purely local
authentication path in the sense that the machine is now subject to attacks
both locally and at the KDC machine.  It also subjects the local machine to
attacks on the network authentication protocol.  Assuming that the protocol is
strong and that the KDC is appropriately protected, then the problem reduces to
the issue of protection of local data.

                    -- Joe Pato
                       Distributed Computing Program / East
                       Hewlett-Packard Company
                       pato@apollo.hp.com

-------
Newsgroups: comp.protocols.kerberos
From: prasad@ISI.EDU (Prasad Upasani)
Subject: Re: Question regarding BSD r commands and kadmin in KB5-BETA2
Reply-To: prasad@ISI.EDU
Organization: USC Information Sciences Institute.
Date: Thu, 12 Nov 1992 02:51:05 GMT

As regards your problem with the bsd rcommands, you are not naming the
srvtab file correctly. This needs go into the directory /krb5, and
should be named v5srvtab.

I do not understand the problem you are having with kadmin. Are you
saying that you sometimes get a message that a principal exists and
sometimes that it doesn't? This seems very strange. kadmind logs all
errors, usually in /usr/adm/messages. You might want to look in here
to see exactly what error kadmind sees.
From: hendrick@ctron.com (James R. Hendrick)
Newsgroups: comp.protocols.kerberos
Subject: Kerb r4 on an SGI ?? Anyone??
Date: 11 Nov 92 17:30:13 GMT
Distribution: comp
Organization: Cabletron Systems Inc.


IRIX 4.0.5 IP12

I need to get this to build for client machines (the kerberos server
will be a SPARC). Does anyone know of the changes needed? This is
fairly important.

Thanks for any help.

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: bcn@ISI.EDU (Clifford Neuman)
Subject: Local password validation (was: kerberizing xlock)
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 23:04:35 GMT

  From: bf4grjc@socrates.MIT.EDU (Ravi Ganesan (301) 595-8439)
  Date: Thu, 5 Nov 92 14:00:50 EST

  I feel that getting a ticket and then getting a service ticket and using that
  service - under the condition the service is on the same machine, is a 
  theoretically messy, but practically convenient solution. (To recap a 
  hyper-kludgy hyper-quick and hyper-dirty way of doing this would be to 
  replace login with a combination of a kinit, a chown on the ticket, and then 
  a quick rlogin into the same machine. Naturally in practice you would set 
  up a dummy server that does something trivial like retun a YES/No 
  repsonse to your login program.

Note that if all you want is to verify the password locally, and if
you do not have a use for subsequent Kerberos authentication, then you
can request a ticket for the "local verification" service in your
first request to Kerberos.  There is no need to first request a ticket
granting ticket.

Also, there is no need to actually contact the local verification
service out of band.  The verification can be done entirely by the
login program.  

What you would do is initially request a ticket for the verification
service, use that ticket to construct an authenticator, then
immediately verify the ticket and authenticator from within the login
program using the "local verification" services key which is
presumably available to the login program since it runs as root.

You could simplify this even further if you were willing to write your
own code to do the verification, instead of using the code in the
Kerberos library.  To do this, you would:

   Make an initial request for a "local verification" server ticket

   Decrypt the response using the password entered by the user

   Decrypt the ticket using the key of the "local verification" server

   Check to make sure the ticket is not expired

   Compare the session key from the ticket with that from the
   response from the KDC.

If they match, and the ticket has not expired, then you have verified
the identity of the user.

	~ Cliff
Newsgroups: comp.protocols.kerberos
From: "a1: :sadler"@mrgate.office.office.decnet.lockheed.com
Subject: Commercial Kerberos
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 12 Nov 1992 00:25:03 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



    



Author:	Connie J. Sadler              
Date:	11-Nov-1992
Posted-date: 10-Nov-1992
Subject: Commercial Kerberos                                                     

    
    I'm with Lockheed Missiles and Space Company and we are piloting 
    Kerberos from MIT, MultiNet Authentication Services from TGV.COM, and 
    others. Any other commercial companies (particularly defense 
    contractors) working with Kerberos? I'd like to share notes and 
    experience.
    
    					Connie Sadler
    					Lockheed Missiles and Space Co.
    
    Reply won't work. Please respond to:
    					 sadler@isvax.lmsc.lockheed.com
    
    
Newsgroups: comp.protocols.kerberos
From: jim@BILBO.SUITE.COM (Jim Miller)
Subject: NTP mailing list?
Reply-To: Jim_Miller@suite.com
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 20:52:42 GMT


Does anyone knows if there is a mailing list that discusses NTP  
issues?

jim-miller@suite.com
Newsgroups: comp.protocols.kerberos
From: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
Subject: Local password validation (was: kerberizing xlock)
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 15:38:32 GMT


   Date: Wed, 04 Nov 92 22:44:07 -0800
   From: Greg Wohletz <greg@duke.cs.unlv.edu>

   In our environment ... I'm  not  particularly
   concerned  if  an imposter gains access to a workstation cpu since all
   he would not actually be able to  do anything useful (nfs, pop,  etc.
   all require kerberos authentication)

**PRECISELY**

We have now come full circle.  Notice that the subject line in this
message contains "was: kerberizing xlock."  This entire conversation
began because people were discussing using Kerberos for local password
authentication, when it was not designed for that purpose.  

With public workstations (like those you described, and those at MIT's
Athena) the spoofability of public workstations is irrelevant.
However, when people start talking about using Kerberos for xlock, it
is clear that they *do* care about an imposter gaining access to a
workstation (particularly given that another user's credentials are
already available there).  In that case, the spoofing issue becomes
highly relevant.

So now, I think, the point has been made and everyone understands the
issues better.  That is, after all, part of the purpose of this
mailing list. :-)

Barry
Newsgroups: comp.protocols.kerberos
From: rjc@MONET.CCS.ITD.UMICH.EDU (Robert John Churchill)
Subject: (none)
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 13 Nov 1992 17:22:56 GMT

> ------- Forwarded Message
> 
> From: schoultz@admin.kth.se (Rickard Schoultz)
> Organization: Royal Institute of Technology, Sweden
> Subject: Summary: klogin clients for PCs, Macs and terminal servers
> Sender: owner-comp-protocols-kerberos@shelby.Stanford.EDU
> To: kerberos@shelby.Stanford.EDU
> 
> 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
> 
> ...
> 
> ------- End of Forwarded Message

Hello... I have been working on a Authentication Manager module for the Mac
and just put up an alpha version for comments.  If you are interested in
looking at it, it is available on  monet.ccs.itd.umich.edu  inside of  /pub

Robert

Newsgroups: comp.protocols.kerberos
From: mqh@theory.TC.Cornell.EDU (Mike Hojnowski)
Subject: The incredible missing Principle trick
Organization: Cornell Theory Center
Date: Thu, 12 Nov 1992 20:51:40 GMT

Hi,

We're running Kerberos V4 here with about 6000 principles.  The server is 
running on an RS/6000 (AIX 3.2.0).  Somehow, for reasons unknown, 8 of our
principles disappeared over the weekend.  They appear in a "kdb_util dump"
on Sunday, and are gone on Tuesday.  The server was not interrupted at all
during that interval.

Anyone seen anything like this before?

Mike Hojnowski
Cornell University
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: ECMA Network Security
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 22:39:15 GMT

Folks ~

Can anyone point me toward online info regarding recent ECMA research work on
network security (presumably OSI).  Thanks in advance.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
From: mamros@athena.lkg.dec.com (Shawn Mamros)
Newsgroups: comp.protocols.kerberos
Subject: Re: safe message problem: HP to 486
Date: 9 Nov 92 15:38:39 GMT
Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
Organization: Digital Equipment Corporation


I noticed the same problem with safe messages between machines with different
byte-ordering a couple months ago (in my case, between a DECstation (little-
endian) and a Sun SPARCstation (big-endian).  I changed the checksum
byte-swapping code in src/lib/krb/rd_safe.c to swap one longword (four bytes)
at a time, and that seemed to fix it.

I also sent my fix to kerberos-bugs@athena.mit.edu, but haven't received
any acknowledgement one way or another.  I have no doubt that this has already
been noticed long before I did, and odds are good there was probably even
a patch posted to this mailing list a long time ago, but I've never seen
any place where "official" fixes to patchlevel 9 have been kept...  For
what it's worth, here's my patchlevel 9-based fix:

*** rd_safe.c   Mon Sep 14 10:25:32 1992
--- rd_safe.c.orig      Mon Jan 23 15:16:38 1989
***************
*** 165,179 ****
       */
  
      bcopy((char *)p,(char *)big_cksum,sizeof(big_cksum));
!     if (swap_bytes) {
!       u_long *swapptr;
!       int i;
! 
!       for (i = 0; i < 4; i++) {
!           swapptr = (u_long *)(big_cksum) + i;
!           swap_u_long(*swapptr);
!       }
!     }
  
  #ifdef NOENCRYPTION
      bzero(calc_cksum, sizeof(calc_cksum));
--- 165,171 ----
       */
  
      bcopy((char *)p,(char *)big_cksum,sizeof(big_cksum));
!     if (swap_bytes) swap_u_16(big_cksum);
  
  #ifdef NOENCRYPTION
      bzero(calc_cksum, sizeof(calc_cksum));


Private messages don't seem to suffer from the same problem... actually, if
you look at rd_priv.c from patchlevel 9, you'll see that the checksum-checking
clause has been #ifdef'd out... sigh.

-Shawn Mamros
E-mail to: mamros@athena.lkg.dec.com
From: djc@scimitar.unx.sas.com (David J. Cherveny)
Newsgroups: comp.protocols.kerberos
Subject: Slave server setup question
Keywords: kprop kpropd
Date: 5 Nov 92 05:02:48 GMT
Organization: SAS Institute Inc.


Assuming version 4, could someone outline to me the master/slave server
setup and operation using kprop and kpropd?  I'm setting up a server and
need redundency.

David Cherveny
SAS Institute, Inc
Newsgroups: comp.protocols.kerberos