From alanc@sac.sfbay.sun.com Tue Jun 16 15:00:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5GM0jk2006246 for ; Tue, 16 Jun 2009 15:00:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5GM0fXa027137; Tue, 16 Jun 2009 15:00:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLC00M1PQH85200@brm-avmta-1.central.sun.com>; Tue, 16 Jun 2009 16:00:44 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLC00LNUQH5D500@brm-avmta-1.central.sun.com>; Tue, 16 Jun 2009 16:00:41 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5GM0f3h004494; Tue, 16 Jun 2009 15:00:41 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5GM0d71006236; Tue, 16 Jun 2009 15:00:39 -0700 (PDT) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n5GM0ddD006232; Tue, 16 Jun 2009 15:00:39 -0700 (PDT) Date: Tue, 16 Jun 2009 15:00:39 -0700 (PDT) From: Alan Coopersmith Subject: XDM-AUTHORIZATION-1 support in libXdmcp [PSARC/2009/362 FastTrack timeout 06/23/2009] To: PSARC-ext@sun.com Cc: Stefan.Teleman@sun.com, xwin-discuss@opensolaris.org Message-id: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6782 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@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 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 From John.Fischer@sun.com Tue Jun 16 16:47:39 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5GNlddF011081 for ; Tue, 16 Jun 2009 16:47:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5GNlc86000150 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Jun 2009 16:47:39 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLC00D0HVFETT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 16 Jun 2009 16:47:38 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLC009IAVFE4530@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 16 Jun 2009 16:47:38 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5GNlbhA004561 for ; Tue, 16 Jun 2009 23:47:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLC00L00UMWNA00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 16 Jun 2009 17:47:37 -0600 (MDT) Received: from [192.168.10.8] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLC00BI9VFDN9G0@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 16 Jun 2009 17:47:37 -0600 (MDT) Date: Tue, 16 Jun 2009 16:46:07 -0700 From: John Fischer Subject: Re: XDM-AUTHORIZATION-1 support in libXdmcp [PSARC/2009/362 FastTrack timeout 06/23/2009] In-reply-to: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> Sender: John.Fischer@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com, xwin-discuss@opensolaris.org Reply-to: John.Fischer@sun.com Message-id: <4A382EBF.1090806@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 7269 +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@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 > 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@opensolaris.org From Darren.Moffat@sun.com Wed Jun 17 02:55:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5H9tNkj003368 for ; Wed, 17 Jun 2009 02:55:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5H9tICO027354 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Jun 2009 10:55:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLD00803NK9NN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 02:55:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLD004A2NK8VQ50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 02:55:20 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5H9tJpl012279 for ; Wed, 17 Jun 2009 09:55:19 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLD00H00N4OR700@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 10:55:19 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLD00IZ7NK47H70@fe-emea-10.sun.com>; Wed, 17 Jun 2009 10:55:16 +0100 (BST) Date: Wed, 17 Jun 2009 10:55:16 +0100 From: Darren J Moffat Subject: Re: XDM-AUTHORIZATION-1 support in libXdmcp [PSARC/2009/362 FastTrack timeout 06/23/2009] In-reply-to: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Alan Coopersmith Cc: PSARC-ext@sun.com, Stefan.Teleman@sun.com, xwin-discuss@opensolaris.org Message-id: <4A38BD84.5030604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1032 Given the standards based nature of this weak crypto I reluctantly give a +1. I will say I'm disappointed in the X.org committee for not allowing the AES to be specified but I understand the reluctance to do so without a sample implementation. ---- 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. ---- The mode of the crypto algorithm isn't listed so I assume this is ECB since there is no mention of space for an IV for it to being CBC mode (and given its age CTR, CCM etc didn't exist back then). So +1 for standards reasons only. If I was to help provide said sample implementation using AES what would it take to get the standard revised ? I'd probably specify it as more than just AES ECB though likely CCM. However given better (non shared secret based) auth methods it just might not be worth it. -- Darren J Moffat From Alan.Coopersmith@sun.com Sat Jun 20 12:16:09 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5KJG9jd011315 for ; Sat, 20 Jun 2009 12:16:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5KJG8bA009885 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 20 Jun 2009 13:16:08 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLJ00203XIW4300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 20 Jun 2009 12:16:08 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLJ0038EXIVIJ70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 20 Jun 2009 12:16:07 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5KJG7XI015524 for ; Sat, 20 Jun 2009 12:16:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLJ00K00X7RR000@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 20 Jun 2009 12:16:07 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLJ005QUXIVII50@fe-sfbay-09.sun.com>; Sat, 20 Jun 2009 12:16:07 -0700 (PDT) Date: Sat, 20 Jun 2009 12:16:07 -0700 From: Alan Coopersmith Subject: Re: XDM-AUTHORIZATION-1 support in libXdmcp [PSARC/2009/362 FastTrack timeout 06/23/2009] In-reply-to: <4A38BD84.5030604@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, Stefan.Teleman@sun.com, xwin-discuss@opensolaris.org Message-id: <4A3D3577.8090903@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> <4A38BD84.5030604@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3131 Darren J Moffat wrote: > Given the standards based nature of this weak crypto I reluctantly give > a +1. Thanks - most of rest of this would apply to a potential future ARC case to add another mechanism, not this case, but since we're already discussing here... > I will say I'm disappointed in the X.org committee for not > allowing the AES to be specified but I understand the reluctance to do > so without a sample implementation. They just wanted one, which is less stringent than IETF's requirement of two implementations before declaring something a standard. The other main roadblock was that the standard was updated by replacing use of DES with AES in a naive fashion - the standards committee members knew enough about crypto to know that correctly specifying use of cryptography can be tricky, and incorrectly doing it can be worse than none at all - as you warned us when we brought up the initial draft on Sun's internal security-interest list in February 2002: "Blindly replacing DES with AES might not actually get you better security, there are sometimes very subtle vulnerabilities that can appear because two encryption algorithms work a slightly different way." I thought I'd later sent out mail asking for review of the draft on that list, when X.Org was asking for crypto experts to give input, but haven't found that in either my saved mail or the list archives, and if I remember correctly, none of the other committee members found crypto experts to review either. > The mode of the crypto algorithm isn't listed so I assume this is ECB > since there is no mention of space for an IV for it to being CBC mode > (and given its age CTR, CCM etc didn't exist back then). The full specification of the DES use in XDM-AUTHORIZATION-1 can be found in the referenced standards document: http://www.x.org/docs/XDMCP/xdmcp.pdf (a copy of which is also in the ARC archives of the case which handled the IPv6 updates to the X standards - PSARC/2004/285/materials/xdmcp.ps ). The encryption details are in section 11, beginning on page 20 of the pdf. > If I was to help provide said sample implementation using AES what would > it take to get the standard revised ? I'd probably specify it as more > than just AES ECB though likely CCM. However given better (non shared > secret based) auth methods it just might not be worth it. Since the original review, X.Org has converted from industry consortium to open source foundation, and doesn't have the same standards process any more. Updating the standard would involve providing patches to the standard spec and sample implementation, and getting them reviewed & accepted by the open source community members. While the original review docs proposing -2 aren't on www.x.org since the website was converted to a wiki a few years ago, they are still available from the internet archive at: http://web.archive.org/web/20040405222753/http://www.x.org/IPV6_Review.html and I still have the original diffs to the troff/.ms source files. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@Sun.COM Tue Jun 23 18:21:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5O1LbY2016022 for ; Tue, 23 Jun 2009 18:21:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5O1Lahe058011 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 23 Jun 2009 19:21:36 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLP00K0DYFY7I00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 23 Jun 2009 18:21:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLP004VJYFX61A0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Tue, 23 Jun 2009 18:21:33 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5O1LXZd000619 for ; Tue, 23 Jun 2009 18:21:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLP00D00YDYLK00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Tue, 23 Jun 2009 18:21:33 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLP00CSJYFXIS70@fe-sfbay-10.sun.com>; Tue, 23 Jun 2009 18:21:33 -0700 (PDT) Date: Tue, 23 Jun 2009 18:21:33 -0700 From: Alan Coopersmith Subject: Re: XDM-AUTHORIZATION-1 support in libXdmcp [PSARC/2009/362 FastTrack timeout 06/23/2009] In-reply-to: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> Sender: Alan.Coopersmith@Sun.COM To: Alan Coopersmith Cc: PSARC-ext@Sun.COM, Stefan.Teleman@Sun.COM, xwin-discuss@opensolaris.org Message-id: <4A417F9D.5090100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906162200.n5GM0ddD006232@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 463 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. Given the +1 and no strenuous objections, this case is now closed approved. Further design discussion of a -2 protocol rev should be taken to the X mailing lists until it is ready to come for review. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering