HDTenEightyP/NetNews huggingface dataset:
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:43:23 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: glenz@ocsg.COM (Glen Zorn)
Subject: Re:  kerberos and xlock
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 5 Nov 1992 19:43:00 GMT

In article <9210291821.AA15017@herring.cmf.nrl.navy.mil>,  
robinson@cmf.nrl.navy.mil writes:

	I'm not subscribed to this mailing list, but I got some forwarded
	e-mail asking about kerborized xlock.  I started on this project
	myself before I found out that it was already done.  The source
	is in:

		/afs/cmf.nrl.navy.mil/X11R4/src/local/xlock

	It works fine as far as I can tell.

	Shell

Does anyone know if this source is available via anonymous FTP?  Thanks in
advance.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
From: deogrady@dsg.cs.tcd.ie (Darragh O'Grady)
Newsgroups: comp.protocols.kerberos
Subject: Kerberos licensing
Keywords: kerberos, license
Date: 6 Nov 92 10:23:40 GMT
Organization: DSG, Dept. of Computer Science, Trinity College Dublin

Does anyone know who in MIT (or elsewhere) to contact with respect to
licensing requirements?

We've got Kerberos running on a network of DECstation. I'd like to know
if the licenses which come with Ultrix Kerberos extend to allow Kerberos
to be used on Sun 4 workstations on the same network.

Thank you for any information.

-- 
Darragh O'Grady  -- deogrady@cs.tcd.ie --    |   If you notice this
Dept. of Computer Science,                   |   notice, then you will
Trinity College,                             |   notice that this notice
Dublin, Ireland.                             |   is not worth noticing.
Newsgroups: comp.protocols.kerberos
From: alan@CURTA.CC.COLUMBIA.EDU (Alan Crosswell)
Subject: telnet encryption option vs. Clarkson TCP
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 9 Nov 1992 21:35:01 GMT

Hello,

I wonder if you have heard of any interoperability problems between
the Kerberized (version 4) telnetd that came with the first beta of
MIT Kerberos 5 and Clarkson TCP for the PC (CUTE-2.2TN-D).

The problem I have is the telnet session "freezes" right around the
TELOPT_ENCRYPTION (option 38) negotiation.  Clarkson TCP is not
capable of doing the auth or encrypt options (boy do I wish!) so it is
just something messing up in the part where the unknown option is
supposed to be rejected.  If I recompile telnetd with -UENCRYPT then
Clarkson TCP is able to get in.  Other telnet clients like Unix and
Kermit can get in just fine.

Tracing the connection shows the freeze up right at this point:
 
> = from telnetd
< = from Clarkson TCP

> IAC Do unknown option (37)
< IAC Won't unknown option (37)
> IAC Will unknown option (38)
< IAC Will terminal type

(the above is based on a sniffer trace)  

The telnet client seems to ignore the Will 38 and doesn't respond,
leaving the telnet server hanging out waiting forever for it and
therefore never continuing and forking up /bin/login.

Trying this with NCSA 2.3 succeeds although it looks like it also
never responds to the 38 (at least based on the message window; we
haven't had a chance to sniff that one yet).  We unfortunately can't
just switch to NCSA 2.3 as our users need TN3270.

Thanks for any light you can shed.
/a
From: eskovgaa@cue.bc.ca (Erik Skovgaard)
Subject: Alliance to develop stack for telephone X.400
Newsgroups: comp.protocols.iso.x400
Date: 6 Nov 92 22:51:58 GMT

Note that I work for PSC, not PSI.

Thanks,                  ....Erik.
Newsgroups: comp.protocols.iso.x400
From: jinho@iti.gov.sg (Tan Jin Ho)
Subject: Uniqueness of X.400 address
Organization: National Computer Board, Singapore
Date: Sat, 7 Nov 1992 16:12:53 GMT

Hi,
        I am new to the X.400 world. I found out the other day
that an X.400 (mnemonic) address conists of country, ADMD, PRMD,
organization, organizational unit, surname, given name, initials, 
and generational qualifier. If this is true, then I am afraid, 
the X.400 address is not unique. 
This is especially true in a Chinese community where
(1) some surnames are prevalent (e.g. Lim, Lee, Tan);
(2) there are a few very popular given names (e.g. Guo Hua, Jian Hua, ...)
(3) generational qualifiers are rare (never see one before)
(4) no middle name
How does people handle the uniqueness of X.400 address in this environment
 ? I can think of a simple solution but would like to hear from the net
(since I'm just starting to look at mail systems).

I was thinking of adding numbers to the name (e.g.
TAN Guo Hua 1, TAN Guo Hua 2, LEE Guo Hua 1, LEE Guo Hua 2). 
Where is the best place to put the numbers '1' and '2' ?
The originator uses the name say "Tan Guo Hua" and the user agent (after 
consulting the directory service) will pop up a list of recipients 
(with additional attributes) for the originator to select.

Does this sound like a reasonable solution ? How do people solve
this problem (I assume somebody else ran into this 
restriction before). The same thing happens to X.500 names too
right ?

While we are at it, has someone done any work on bringing X.400
address to the residential environment (street address, locality, ...)
? The Red Book mentioned a little about this, but is there any 
implementation that does this ?

Regards,
Jin-Ho
jinho@iti.gov.sg
^^^^^
I have 'uncommon' name 8^P
Newsgroups: comp.protocols.iso.x400
From: Stef@nma.com (Einar Stefferud)
Newsgroups: comp.protocols.iso.x400
Subject: Re: Help me
Date: 6 Nov 92 08:20:16 GMT
Article-I.D.: nma.6595.721034324
Reply-To: Stef@nma.com
In-reply-to: Your message of 22 Sep 1992 02:23:46 +0000.
             <9209220223.AA11255@sorel.kotel.co.kr>

Hi -- I am the Chair of IFIP WG 6.5.  What kind of information would
you like to receive?		Best Regards...\Stef
Newsgroups: comp.protocols.iso.x400
From: fredy@nibelung.Worms.Fh-Rpl.DE ()
Subject: X.400- Protocol- description
Date: Fri, 06 Nov 1992 11:56:49 GMT
Distribution: dnet
Reply-To: fredy@nibelung.Worms.Fh-Rpl.DE ()
Organization: Fachhochschule-Rheinland-Pfalz

Who knows where i can get a full description ( bit - level) of X.400 Protocol
(X.400 (84 und 88)) ?
Please send a mail to me!

With best regards 

Fredy Zaegel

Science lab for commmunication of
University of Worms
Erenburger Str. 19
6520 Worms
Fax.: 06241 /509221
From: Paul.Rarey@ssf-sys.dhl.com ("Paul.Rarey")
Subject: Re: X400 address
Encoding: 47 TEXT, 12 TEXT SIGNATURE
X-Mailer: Poste 2.0
Newsgroups: comp.protocols.iso.x400
Date: 5 Nov 92 14:33:32 GMT



> [Discussion of the semantics of ADMD=" " deleted]
> :
> : | I don't know of -any- country where this is actually the case.
> :
> : Mabey  not,  but shouldn't the community at large try to leverage  it
> : into existance?  Wouldn't we be better off for it?
>
> Sure (I would be more than happy if we could get rid of the implicit
> vendor lock in in X.400 and move to a really competitive market), but
> I just see a lot of practical difficulties: for example for ADMD=" "
> to be useful it requires that PRMD names to unique in a country (the bit
> you didn't quote from X.402(88) 18.3.1).

The  Internet  Domain Naming System has similar issues.  All  domains
immediately  under,say, "COM" require unambiguity, but there seems to
be  no real problem there.  Also, COM is international in scope,  not
specific to a country.

All  that  is  really  needed is  a  naming  authority  appropriately
chartered  by  commercial  enterprise or where  necessary,  by  local
government.  I don't mean to over trivialize the issue, but we're not
inventing  something  here.  There is plenty of foundation of how  to
manage unambiguous names within a hierarchy.

> :
> : |   - if they can route to all the recipients of a message (even if
> : |     they are not responsible for the address).
> :
> : Is  it common practice to send probes before any message, or just  if
> : they are over a certain size?
>
> I don't know of any ADMD that uses probes,  the address is considered
> valid if (this is the way PTT ADMD's seem to behave):
>
>   - it is a PRMD in the ADMD with a mta connected to the ADMD.
> or
>   - it is in an ADMD that is connected to the ADMD.

  or

    - it is an ADMD that is "reachable" through interconnectivity and
      "settlement" arrangements.

"Settlement"  in this last bullet is an unfortunate aspect of current
reality.



    Best regards...,


    Paul S. Rarey           DHL Systems Inc.
    Open Systems Research   1700 S Amphlett Blvd  Phn: (415) 358-5522
    Global Communications   San Mateo, CA  94402  FAX: (415) 571-7073

    INet:      Paul.Rarey@ssf-sys.DHL.COM
    X400:      PN=Paul.Rarey;O=SYSTEMS;P=DHL;A=MARK400;C=US
From: poole@chsun.chuug.ch (Simon Poole)
Newsgroups: comp.protocols.iso.x400
Subject: Re: X400 address
Date: 5 Nov 92 11:22:51 GMT
Organization: CHUUG/EUnet
X-Newsreader: Tin 1.1 PL3

Paul.Rarey@com.dhl.ssf-sys (Paul.Rarey) writes:

[Discussion of the semantics of ADMD=" " deleted]
: 
: | I don't know of -any- country where this is actually the case.
: 
: Mabey  not,  but shouldn't the community at large try to leverage  it
: into existance?  Wouldn't we be better off for it?

Sure (I would be more than happy if we could get rid of the implicit
vendor lock in in X.400 and move to a really competitive market), but
I just see a lot of practical difficulties: for example for ADMD=" " 
to be useful it requires that PRMD names to unique in a country (the bit 
you didn't quote from X.402(88) 18.3.1).

: 
: |   - if they can route to all the recipients of a message (even if
: |     they are not responsible for the address).
: 
: Is  it common practice to send probes before any message, or just  if
: they are over a certain size?

I don't know of any ADMD that uses probes,  the address is considered
valid if (this is the way PTT ADMD's seem to behave):

	- it is a PRMD in the ADMD with a mta connected to the ADMD.
or 
	- it is in an ADMD that is connected to the ADMD.

-- 
CHUUG/EUnet Switzerland				Simon Poole
Zweierstrasse 35	Tel: +41 1 291 45 80	poole@eunet.ch
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=poole;P=EUnet;A=EUnet;C=CH
From: Stef@nma.com (Einar Stefferud)
Subject: Re: X400 address
In-reply-to: Your message of 05 Nov 1992 16:30:30 +0000.
             <1992Nov5.163030.29308@chsun.chuug.ch>
Newsgroups: comp.protocols.iso.x400
Reply-To: Stef@nma.com
Date: 6 Nov 92 02:51:45 GMT

Simon and Paul --

I believe the problem is solved if we just choose another name for the
virtual ADMD Service that is described in X.402 for AMDMD=" ", adn get
our fellow ADMD service providers to sell message exchange services to
PRMD operators that sign up for this service.

All that is needed is for the cooperating service providers to
exchange reachability information (E.g., DNS MX type information), adn
then go aobut their business of routing and switching mail.

Thsi is the model that I expect to underlay C=US; A=INTERNET, and we
will surely invite the commercial ADMD service providers to support
A=INTERNET by attaching to the Internet and exchanging mail with
A=INTERNET values in ORAddresses.

Those who do will find a revenue source in the Internet connection,
and those who don't won't.

N% of something is more than 100% of nothing...\Stef
From: /PN=Thomas.K.Hinders/OU=CCMAIL/O=CHAN.IS/PRMD=MMC/ADMD=TELEMAIL/C=US/@sprint.com
Subject: DDA and PRMD/S fields
Newsgroups: comp.protocols.iso.x400
X-Message-Id: <"392517071192"*/PN=Thomas.K.Hinders/OU=CCMAIL/O=CHAN.IS/PRMD=MMC/ADMD=TELEMAIL/C=US/@sprint.com>
Date: 9 Nov 92 17:12:40 GMT

    A question regarding  DA's. The 84/88 standard requires that if
    you use a DDA you must also specify a PRMD or S field.

    Why?  I can understand the PRMD, but not the S. And for a mail system,
    like MCImail, which does not use a PRMD, they "throw away" the S field.

    Thanks....................


                                Thomas K Hinders
                       Martin Marietta Computing Standards
                             4795 Meadow Wood Lane
                               Chantilly, VA 22021
                        703.802.5593 (v) 703.802.5027 (f)
From: Stef@nma.com (Einar Stefferud)
Subject: Re: RFC 1237 - proposed fix
In-reply-to: Your message of Sun, 08 Nov 1992 09:29:08 +0000.
             <1085.721214948@isode.com>
Newsgroups: comp.protocols.iso.x400.gateway
Reply-To: Stef@nma.com
Date: 9 Nov 92 00:07:05 GMT

I understand and strongly agree that they are just numbers, but in the
end, people seem to attach much more meaning to their roots than they
should, so OID choices become political.

It turns out that one of the places where we can tolerate political
influences to have some impact is in the choice for these numbers,
especially if it makes other political things easier.

In the case of Internet use, it seems to me that it already is
important for us to get and use a truly international rooted OID, and
to do it as soon as possible to make the choices obvious and easy for
everyone in the Internet community.

Lyman -- How goes the effort to get an ICD? Cheers...\Stef
From: S.Kille@isode.com (Steve Hardcastle-Kille)
Subject: Re: RFC 1237 - proposed fix
In-reply-to: Your message of Sat, 07 Nov 92 16:09:16 -0800. <10662.721181356@nma.com>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Newsgroups: comp.protocols.iso.x400.gateway
Date: 8 Nov 92 09:36:51 GMT
Phone: +44-71-223-4062

Could do.    I also have a BSI allocated OID if you prefer this.   Or
could ask Jon for one.  No strong feelings - they are just numbers.

Steve
From: S.Kille@isode.com (Steve Hardcastle-Kille)
Subject: RFC 1237 - proposed fix
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Newsgroups: comp.protocols.iso.x400.gateway
Date: 7 Nov 92 19:54:32 GMT
Phone: +44-71-223-4062

I propose the following fix to RFC 1327.   This assigns an entirely
new OID.  The one widely deployed implementation does not follow
the specification either as written or intended (it truncates the long
number to four octets).     The proposed change

1) Corrects the specification
2) Removes the problem of the long digit
3) Moves the whole assignment to a safe part of the OID space
   (0.9.2342 is questionable - this is being discussed in the
   OSI-DS group).


Could this revised text be discussed at the X400-ops WG in DC?


Steve



     Appendix D - Object Identifier Assignment


     An object identifier is needed for the extension IPMS element.
     The following value shall be used.


     x400-rfc822 OBJECT IDENTIFIER ::=
         {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1)
	  isode-consortium (453) x400-rfc822(9)}


     id-rfc-822-field-list OBJECT IDENTIFIER ::= {x400-rfc822 field(1)}
From: Stef@nma.com (Einar Stefferud)
Subject: Re: RFC 1237 - proposed fix
In-reply-to: Your message of Sat, 07 Nov 1992 15:21:08 +0000.
             <5886.721149668@isode.com>
Newsgroups: comp.protocols.iso.x400.gateway
Reply-To: Stef@nma.com
Date: 8 Nov 92 00:17:56 GMT

I have recently had a message exchange with Lyman with regard to ISOC
quickly getting an ICD from BSI for IAB/IETF use.  If that has been
accomplished, it might be much much better to use an OID branch under
it, if we can organize things fast enough...\Stef

+++++++++++++

From message <5886.721149668@isode.com> :
>I propose the following fix to RFC 1327.   This assigns an entirely
>new OID.  The one widely deployed implementation does not follow
>the specification either as written or intended (it truncates the long
>number to four octets).     The proposed change
>
>1) Corrects the specification
>2) Removes the problem of the long digit
>3) Moves the whole assignment to a safe part of the OID space
>   (0.9.2342 is questionable - this is being discussed in the
>   OSI-DS group).
>
>Could this revised text be discussed at the X400-ops WG in DC?
>
>Steve
>
>     Appendix D - Object Identifier Assignment
>
>     An object identifier is needed for the extension IPMS element.
>     The following value shall be used.

>     x400-rfc822 OBJECT IDENTIFIER ::=
>         {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1)
>	  isode-consortium (453) x400-rfc822(9)}
>
>     id-rfc-822-field-list OBJECT IDENTIFIER ::= {x400-rfc822 field(1)}
Newsgroups: comp.protocols.iso.x400
From: dave@philips.oz.au (David Torr)
Date: Mon, 9 Nov 92 23:54:05 GMT
Organization: Philips Public Telecommunications Systems, Melbourne, Australia
Subject: Re: Uniqueness of X.400 address
Distribution: world

jinho@iti.gov.sg (Tan Jin Ho) writes:

>Hi,
>        I am new to the X.400 world. I found out the other day
>that an X.400 (mnemonic) address conists of country, ADMD, PRMD,
>organization, organizational unit, surname, given name, initials, 
>and generational qualifier. If this is true, then I am afraid, 
>the X.400 address is not unique. 
>This is especially true in a Chinese community where
>(1) some surnames are prevalent (e.g. Lim, Lee, Tan);
>(2) there are a few very popular given names (e.g. Guo Hua, Jian Hua, ...)
>(3) generational qualifiers are rare (never see one before)
>(4) no middle name
>How does people handle the uniqueness of X.400 address in this environment
> ? I can think of a simple solution but would like to hear from the net
>(since I'm just starting to look at mail systems).

>I was thinking of adding numbers to the name (e.g.
>TAN Guo Hua 1, TAN Guo Hua 2, LEE Guo Hua 1, LEE Guo Hua 2). 
>Where is the best place to put the numbers '1' and '2' ?
>The originator uses the name say "Tan Guo Hua" and the user agent (after 
>consulting the directory service) will pop up a list of recipients 
>(with additional attributes) for the originator to select.

>Does this sound like a reasonable solution ? How do people solve
>this problem (I assume somebody else ran into this 
>restriction before). The same thing happens to X.500 names too
>right ?

>While we are at it, has someone done any work on bringing X.400
>address to the residential environment (street address, locality, ...)
>? The Red Book mentioned a little about this, but is there any 
>implementation that does this ?

>Regards,
>Jin-Ho
>jinho@iti.gov.sg
>^^^^^
>I have 'uncommon' name 8^P

Not sure how the Chinese world is catered for, but X.400 (at least in the days
long ago when I worked on 84 version) is very ASCII orientated - I remember
the first customer for a product I was involved with was in Norway, where they
use extended characters - and guess what - these were (are?) not legal in
X.400 ORNames!

Guess countries that use characters other than the standard US/UK ones need
to contribute more to ISO and CCITT?????

Hopefully the situation is better now - is it???
-- 
Dave Torr                                   dave@philips.oz.au
Software Development Manager                Tel +61 3 881 3587
Philips Public Telecommunications Systems   Fax +61 3 883 3577
Views expressed are personal and do not necessarily reflect Philips' policy.
Newsgroups: comp.protocols.iso.x400
From: hta@boheme.er.sintef.no (Harald Tveit Alvestrand)
Subject: Re: Uniqueness of X.400 address
Reply-To: harald.alvestrand@delab.sintef.no
Organization: SINTEF DELAB, Norway
Date: Tue, 10 Nov 92 08:15:27 GMT

There are 2 solutions in the X.400/88 standard to the character set problem
in O/R names.

1) Allow TeletexStrings in O/R name attributes
   TeletexStrings allow ISO-IR-87, which is a Japanese character set.
   (they probably had a man on the comittee...Greek and Arabic are still out)
2) Allow Directory Names instead of O/R names to be used in submission.
   This allows looking up the "real" name from X.500.

(why standardize one solution when you can standardize two :-)

In both cases, you can see the hand of ADMDs trying to protect their
previous investment: whenever an O/R name is passed across an international
boundary, it is supposed to have all attributes represented in Printable
(that is, USASCII without some characters) IN ADDITION TO other forms.

People are thinking now that an address should be for machines, not people.
I would not like to have to consider Chinese (or Norwegian) characters
for my routing tables, even though my son's name cannot be written in ASCII.

As for uniqueness, this is a local matter. 
Often, use of OUs will be sufficient.

But I know of an organization where two people with the same name worked in
the same OU; one of them got an arbitary middle initial.

-- 
                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94
Newsgroups: comp.protocols.iso.x400
From: hta@boheme.er.sintef.no (Harald Tveit Alvestrand)
Subject: Re: X400 address
Reply-To: harald.alvestrand@delab.sintef.no
Organization: SINTEF DELAB, Norway
Date: Fri, 6 Nov 92 10:16:05 GMT

1) The correct address is C=no;admd= ;prmd=uninett;O=UNINETT;s=mhsnews-request
                                                   ^^^^^^^^^
   If you are using an X.400 service that does not route on c=no;admd= , you
   may try

   C=no;admd=uninett;prmd=uninett;O=uninett;s=mhsnews-request

2) The requirement for PRMD uniqueness under ADMD=  is that
   all PRMDs *USING ADMD= * have to be unique.
   This is one of the things that have led Stef into proposing ADMD=USBB
   instead of ADMD=  in the US - it is simply *VERY* like an ADMD.
   (I don't agree that USBB is better than " " - but that is another discussion)
-- 
                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94
Newsgroups: comp.protocols.iso.x400
From: hta@boheme.er.sintef.no (Harald Tveit Alvestrand)
Subject: Re: Alliance to develop stack for telephone X.400
Reply-To: harald.alvestrand@delab.sintef.no
Organization: SINTEF DELAB, Norway
Date: Mon, 9 Nov 92 09:52:38 GMT

One important thing I forgot to mention:

I am NOT the mailing list maintainer for this group.
I only crossposted it.

For further info:
 Contact Frode Hernes <Frode.Hernes@maxware.noprmd.telemax.no>
                       C=no;ADMD=telemax;O=maxware;S=Hernes;G=Frode
-- 
                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94