Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)

From: Mark Daniel (Mark.Daniel_at_wasd.vsm.com.au)
Date: 06/03/03 

Date: Tue, 03 Jun 2003 09:23:43 +0930

Fred Kleinsorge wrote:
> It just a matter of priorities, time, and resources.

Yes.

> Motif V1.3 was done primarily in response to the needs of software like JAVA
> for client features in X11R6.x. The refresh brought both the server and
> client bits up to the current release. It also brought along with it a
> number of features that had not previously been available - Magic-Cookie,
> and Kerberos just being a few - some of which were needed by DII/COE.

Yes. A Sun environment in drag.

> The XDM implementation is not provided as part of Motif or the base OS -
> instead it is a component of the TCPIP product. So it is not that it was
> "overlooked" - it wasn't part of the Motif project.

This beggars belief Fred. It's a little like saying the TCP/IP product
included an XDM but it can't be used with DECwindows (yet) because the XDM
project did not include the provision of hooks into the Session Manager.

> The OpenVMS priority right now is focused on the delivery of OpenVMS on
> Itanium. With the underlying Magic-Cookie support now available, I imagine
> at some point XDM Magic-Cookie support will follow, your request to the
> TPCIP group should help make sure that it is on their future work list.

Would the provision of the XDM be more appropriately positioned with the
DECwindows group? This is where the XFS resides, which is also a TCP/IP
based server.

> As to 24-bits... simply change the pixel depth. Most of the cards we ship
> today support 8, 16 and 24 bit depths. The default depth of 8 is mostly
> historical and performance driven. The Radeon 7500 will have a 24-bit
> default. I run my personal workstation (with the Oxygen VX1) at 1920 x 1200
> @ 16bits.

We no longer generally use desktop workstations Fred. Too expensive and
not necessary for our activity profile. The post and issue concerns the
necessity for the comprehensive support of the X Window System for
thin-client environments (remember, we are replacing *X-terminals*, and the
colour depth was one of multiple issues).

I am unsure what your working environment is like Fred. Ours (probably in
keeping with many non-commercial) requires access to multiple applications
distributed across multiple platforms. VMS (currently) has a place in
this. There are also multiple Unices in use and Windows Terminal Server.
The one desktop applicance needs access to any or all of these. VMS needs
to integrate seamlessly into this heterogeneity. In some instances the one
desktop also needs to allow multiple uses and users to host their sessions.
  It is not only an annoyance if access controls need to be disabled when
starting a VMS hosted application (now addressed with 1.3) or session but
unproductive and counter security policy in many circumstances as well. It
also raises complaints (which VMS could well do without) from those who
have no interest or investment in O/S idiosyncracies, platform
dependencies, the vendors' time, resources and priority allocations.

Of course, this is preaching to the converted. I am not wishing to dwell
on the bleeding obvious here (or unduly to sound like much of the banter in
this forum). I just wish to emphasize that the much-needed update of
DECwindows without any corresponding functionality changes in a fundamental
component of that X environment is a significant anomaly that would be best
receiving immediate attention (project management boundaries notwithstanding).

Thanks for listening.

> "Mark Daniel" <Mark.Daniel@wasd.vsm.com.au> wrote in message
> news:3EDAD271.3040302@wasd.vsm.com.au...
>
>>I am not really wishing to start a "this is typical of DEC/CPQ/HP OpenVMS
>>Management ..." thread. Please restrain the impulse to do so if this post
>>just reinforces your experience over the years. If there are others out
>>there in this same situation it just might be an opportunity to inform
>>those OpenVMS Engineering Project Managers who frequent and now are often
>>active in these newgroups, of what (I feel is) a very basic requirement.
>>
>>This relates to my day-job (DSTO), not the proprietory company represented
>>by my email address (VSM). That really dosn't change anything of course.
>>Small organizations as well as large are equally dependent the ubiquitous
>
> X
>
>>Window System environment.
>>
>>We are in the process of replacing a large number of older X-terminals
>
> that
>
>>provide only 8 bit colour with those supporting 24 bits (amongst other
>>reasons). In so doing we discovered that a candidate solution (which best
>>goes unspecified in this forum) requires the support of
>
> MIT-MAGIC-COOKIE-1.
>
>> Now, I don't want to debate the efficacy of the this method of
>>"authentication" or privacy insurance. Suffice to say it *is* a
>>requirement. It is also a "policy" that such such an authentication
>
> scheme
>
>>be used with X-terminals to reduce the possibility of unauthorized clients
>>accessing sensitive information, including displays, entered passwords,
>>etc. In other words, all the stuff that the standard X Window System so
>>promiscuously allows. Up until now we have not been able to implement the
>>"policy" on our VMS systems because we use TCP/IP extensively as a
>>transport and DECwindows 1.0->1.2 has only supported user-based
>>authentication for DECnet, or the XDM-AUTHENTICATION-1 which is cumbersome
>>and was not practicable (at least in our environment).
>>
>>Motif 1.3 has changed this. It supports MIT magic and works well. (Many
>>thanks to the specialist handling the call at our national CSC for chasing
>>this down and obtaining a copy for us well before we would have received
>
> it
>
>>on the Q2 distribution.) OK, all is well. Hmmm, not quite. After time
>>and effort was expended getting the XDM to support the MIT_MAGIC-COOKIE-1
>>authentication it still didn't. And won't! You see, apparently all of
>>OpenVMS' X Display System (DECwindows) has received a major overhaul
>
> EXCEPT
>
>>THE XDMCP tool! Yes, the XDM was "overlooked" (?) and does not provide
>>what the rest of the suite does.
>>
>>When I pressed my contact at the CSC he relayed his impression from
>
> OpenVMS
>
>>Engineering over this issue. I quote (with permission) my reply here
>
> (with
>
>>only some private detail removed) so as not to have to recompose the same
>>sentiments. He understood the remarks and is forwarding them to the
>>"whomever". Thanks for your reading time.
>>
>>
>>>From: Daniel, Mark Sent: Monday, June 02, 2003 11:17 AM
>>>Subject: RE: magic cookies
>>>
>>>Hi [name],
>>>
>>>
>>>>Sigh... I thought we were well past "yes/no", you can't do it with
>>>>XDM. We've been trying to raise this as a "please fix
>>>
>>>My mistake. I thought we were still in the "get the folks back home to
>>>tell us how" stage :^)
>>>
>>>
>>>>this ASAP", but getting lots of "yeah, sure, after Itanium ships" type
>>>>noises. :-(
>>>
>>>Never thought I'd be so exasperated. I know I'm not telling you
>>>anything new [name], just expressing myself out loud. Perhaps you can
>>>return this reply verbatim to "whomever".
>>>
>>>Not wishing to again express any opinion over the essential value of MIT
>>>magic cookie style authentication, it is so fundamental a part of
>>>heterogenous environments (which we all live in these days) that for it
>>>to be absent is tantamount to illuminating a neon sign over VMS saying
>>>"DOES NOT FIT IN". VMS does not need to draw attention to itself in
>>>*this* way. Now, MIT magic in Motif 1.3 is an *excellent* move. BUT,
>>>it's only half done if the XDMCP tool does not support it!! Thin-client
>>>environments just cannot be supported without an effective XDM. I would
>>>have thought this would have been obvious to blind-Freddy. I'm
>>>surprised that someone in the DECwindows Motif 1.3 enhancement project
>>>did not notice this, or did not state long and loud that the XDM is an
>>>essential component of the VMS X Display System environment. Perhaps it
>>>should be wrested from the TCP/IP team, or some better coordination
>>>between them and DECwindows project management. Perhaps it is just Too
>>>Hard.
>>>
>>>
>>>>Can you give me a rough dollar value on what we could sell you guys if
>>>>we delivered this capability? If not dollars, then some number of DS??
>>>>systems? As they say, money talks.
>>>
>>>Ignoring the issue of future Itanium sales :^) Perhaps you might remind
>>>the bean counters that new systems aside, my Division retains hardware
>>>and software maintenance on the existing systems. I just enquired of
>>>our IT Manager and for this Division alone it's in the order of
>
> [considerable number]
>
>>>Australian beans per annum, the majority of which is for VMS systems
>>>(perhaps not major customer status, but significant, I'd say,
>>>"money-for-jam"). Considering the reported disparity in margins between
>>>sales of new iron and that for "services", I would suggest that OpenVMS
>>>first strive to retain this income stream before asking how much more
>>>we'll spend next year. In fact it is probably from this source that
>>>ports to Itanium are being funded. Nobody is debating that now the
>>>Alpha platform has been declared obsolescent that a
>>>Itanium/Opteron/whatever port is necessary and inevitable but not to the
>>>exclusion of much else that is necessary.
>>>
>>>
>>>>Or would we be giving sales to [platform]? XP workstations give heaps
>
> more
>
>>>>than 8 bit colour depth. DS10 or DS15 instead maybe? Wouldn't need
>>>>magic cookies at all...
>>>
>>>Still would. It has now come to the attention (after the need to
>>>explain why we can't support VMS sessions on [platform] - at least
>
> before
>
>>>Motif 1.3) of our IT Security Officer that those using VMS have no
>>>connection authentication enabled on their X-Terminals.
>>>Needless-to-say, "this needs to be addressed".
>>>
>>>
>>>>[signature]
>>>
>>>Hope this is of some value.
>>>
>>>Regards,
>>>
>>>Mark Daniel.
>>
>
>

Relevant Pages

  • Re: Banana Republic (was Re: OpenVMS Book Wins award)
    ... and just use INETd on the server and be done with it. ... anything non-trivial in VMS' AST-driven environment is familiar with ... least as it is understood in a VMS context. ... you necessarily cater to the minimum common denominator - the browser. ...
    (comp.os.vms)
  • A good man is never honoured in his own country
    ... for any VMS development shop. ... The number of vendors currently selling Web server ... Much of the development of WASD during the first couple of years took ... The primary impetus for an internal Web environment was a 1993 ...
    (comp.os.vms)
  • Re: Looking for replication technique for cluster VMs to offsite
    ... ever thought about Campus Cluster? ... It works with dynamic disks in a cluster environment. ... From Licensing Microsoft Server Products with Microsoft Virtual Server R2 ... (we have about 10 VMs) ...
    (microsoft.public.windows.server.clustering)
  • RE: Binding Windows Services to Specific Addresses Only
    ... Document the server. ... If this is a corporate environment, ... Install the minimums. ... The network configuration for the server should restrict what the server has ...
    (Focus-Microsoft)
  • Re: System.Security.SecurityException: Request
    ... but this may be because my local server does not have ... for the permission of type ... eventArgument) +7 ... Mscorlib.dll controls the access to the user environment variables. ...
    (microsoft.public.dotnet.framework.aspnet)