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 at sun.com
Sun Microsystems, Inc. - X Window System Engineering
