+1
Alan Coopersmith wrote:
> I am sponsoring this fasttrack for Stefan Teleman of the X team.
> The timer is set for next Tuesday, June 23, 2009.
>
> While the design decisions made by XDM-AUTHORIZATION-1 are clearly
> inappropriate today (Triple-DES encryption of an string containing
> a network address limited to 32 bits (i.e. IPv4 only, no v6)), this
> case is about interoperability with this existing, 15-year old,
> widely implemented standard, not designing new protocols for today.
>
> When I submitted the draft version of what became the XDMCP 1.1
> standard to X.Org, it included a proposal for XDM-AUTHORIZATION-2
> which would have supported IPv6 and used AES instead - the X.Org
> standards body decided to defer that support until someone wanted
> it badly enough to provide a sample implementation for evaluation.
>
> Since that did not happen during the standards review of the IPv6
> changes, XDMCP 1.1 was published without it (resulting in the
> "curious" situation Stefan notes below) - since that still has not
> happened, XDM-AUTHORIZATION-1 remains in its limited state, but still
> utilized and interoperable with existing implementations. (The most
> common alternative, MIT-MAGIC-COOKIE, is a simple ascii encoding of the
> output of a random number generator such as /dev/urandom, so it's not
> like this is much worse of a method of generating a shared secret,
> it's just not really any better either.)
>
> -Alan Coopersmith- alan.coopersmith at sun.com
> Sun Microsystems, Inc. - X Window System Engineering
>
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> XDM-AUTHORIZATION-1 support in libXdmcp
> 1.2. Name of Document Author/Supplier:
> Author: Stefan Teleman
> 1.3 Date of This Document:
> 16 June, 2009
> 4. Technical Description
>
> Including XDMAUTH with X11 in Solaris
>
> Stefan Teleman <stefan.teleman at Sun.COM>
> 11 June 2009
>
> 1. Summary and motivation
>
> XDMCP [ The X Display Manager Control Protocol ] provides for
> several possible authentication mechanisms:
>
> - MIT-MAGIC-COOKIE-1
> - XDM-AUTHORIZATION-1
> - SUN-DES-1
> - MIT-KERBEROS-5
>
> Not all of these authentication mechanisms are available in all
> builds or implementations.
>
> The XDM-AUTHORIZATION-1 mechanism is similar to the MIT-MAGIC-COOKIE-1
> mechanism: a key is stored in the .Xauthority file, and is shared
> with the X server. This key consists of two parts - a 56-bit DES
> encryption key and 64 bits of random data used as the authenticator.
>
> XDM-AUTHORIZATION-1 is only available if libXdmcp was compiled with,
> and provides run-time support for, this mechanism. Such support is
> discovered at software construction time [ ./configure ], by
> checking for the presence of one translation unit, not necessarily
> named Wraphelp.c. This translation unit provides implementations
> for two C functions with private API binding:
>
> void _XdmcpAuthSetup(auth_cblock key, auth_wrapper_schedule schedule);
> void _XdmcpAuthDoIt(auth_cblock input, auth_cblock output,
> auth_wrapper_schedule schedule, int flag);
>
> Various different implementations of the two functions mentioned
> above are possible. Regardless of implementation, conformance to
> the canonical prototypes defined for these two functions is expected
> and assumed.
>
> Until now, Solaris has not provided support for XDM-AUTHORIZATION-1
> authentication. This Case proposes the inclusion of this XDMCP
> authentication mechanism with Solaris.
>
> This Case seeks Micro/Patch release binding.
>
> 2. Technical issues
>
> 2.1. Key Objects
>
> libXdmcp.so.6
>
> This library is, and has been for some time, present in Solaris,
> but without the _Xdmcp* interfaces exposed by Wraphelp.o, therefore
> without support for XDM-AUTHORIZATION-1.
>
> 2.2. ABI and API Considerations
>
> Introducing support for XDM-AUTHORIZATION-1 does not create ABI or
> API incompatibilities: the two functions mentioned above are simply
> added to the existing libXdmcp.so.6 API. Given that libXdmcp.so.6
> is written in C, and that these two new functions have private
> binding, there are no ABI compatibility issues; the introduction
> of these new functions does not require, or create, modifications to
> the existing libXdmcp.so.6 API.
>
> The particular details of any given implementation of the _Xdmcp*
> functions are irrelevant to the libXdmcp.so.6 interface consumer:
> the only concern is whether or not these interfaces are available.
>
> 2.3. Known limitations
>
> XDM-AUTHORIZATION-1 implements a TDES [ FIPS 46-3 ] [1] based access
> control mechanism [ as per description above ]. Environments with
> more stringent security requirements may consider cryptologically
> stronger ciphers more appropriate.
>
> XDM-AUTHORIZATION-1 stores secret data in the .Xauthority file
> [ similar to MIT-MAGIC-COOKIE-1 ]. Obtaining read access to a
> user's .Xauthority file is a security breach: authentication data
> can be read from a user's .Xauthority file and can be written to a
> different .Xauthority file by the xauth(1) program, thereby granting
> authenticated access to the Xserver.
>
> In addition, XDM-AUTHORIZATION-1 only supports TCP/IPv4 connections.
> Although RFE's for a TCP/IPv6 implementation have been discussed,
> no default implementation based on TCP/IPv6 has been provided to
> date. TCP/IPv6 is explicitly excluded [ by omission ] from the XDMCP
> Specification. Curiously enough, UDP/IPv4 and UDP/IPv6 are explicitly
> discussed in the same Specification.
>
> In spite of these known limitations, including XDM-AUTHORIZATION-1
> is a Protocol Standard conformance requirement.
>
> A future ARC Case may discuss the introduction and design of a more
> flexible, secure and sophisticated implementation of the XDMCP
> authorization mechanism: MIT-KERBEROS-5. [2]
>
> 2.4. Documentation
>
> PostScript documentation for the XDMCP Specification and the
> XDM-AUTHORIZATION-1 authorization mechanism is available. [3]
> Documentation of the library API is not available.
>
> 3. Interfaces
>
> 3.1. Interface Stability
>
> The prototypes for the two functions mentioned above have not
> changed at least since X11 Release 6. This case does not propose
> altering the current Interface Stability Classification [ Committed ]
> currently in effect for libXdmcp.so.6.
>
> 3.2. Interface Dependencies and Compatibility
>
> Introducing XDM-AUTHORIZATION-1 in libXdmcp.so.6 does not create
> additional compile-time, or run-time, dependencies for the library.
>
> 4. References
>
> [0] http://www.x.org/
> [1] http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
> [2] http://web.mit.edu/Kerberos/
> [3] http://www.x.org/docs/XDMCP/
>
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> X Consolidation / Desktop C-Team
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
>
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
