A Defence of SESAME
Tom Parker
A DEFENCE OF SESAME
The second edition of "Applied Cryptography" by Bruce Schneier
contains the following paragraphs criticising the European Open
Systems SESAME technology:
"SESAME is an authentication and key exchange system. It uses
the Needham-Schroeder protocol, with public-key cryptography to
communicate between different security domains. The system is
seriously flawed in several respects. Instead of using a real
encryption algorithm, they use XOR with 64-bit key size. Even
worse they use XOR in CBC mode which leaves half the plaintext
unencrypted. In their defense, they planned on using DES until
the French government complained; they validated the code with
DES but then removed it, and expect people to add it back. I am
unimpressed nonetheless.
"Authentication in SESAME is a function on the first block of a
message, not on the entire message. This has the effect of
authenticating 'dear sir', and not the body of a letter. Key
generation consists of two calls to the UNIX rand function,
which isn't very random. SESAME uses crc32 and MD5 as one-way
hash functions. And of course, SESAME is vulnerable to
Kerberos-like password guessing."
In January of this year I wrote to Mr Schneier defending SESAME
against these criticisms. The mail I sent follows below, I received
an automated confirmation from his mailbox of receipt of this mail.
In view of the failure of Mr Schneier to reply to this mail,
or to a later gentle reminder, also automatically confirmed as being received,
I must now go public on behalf of the SESAME project. Here is the letter.
Dear Mr Schneier,
I have read your description of the SESAME technology in
section 24.7 of your recent Second Edition of "Applied
Cryptography". I would like to raise a few points with a view
to corrections being made for the third edition, or even better
for you to issue an erratum. I am writing to you privately at
this stage since I am reluctant to start a public defence of
SESAME on the Internet; this could lead to bad feeling and
controversy that I am anxious to avoid.
Although perhaps you didn't intend it, I am afraid that the
description is slanted in two respects and inaccurate or
slanted in another, even assuming you were reviewing the old
SESAME V2. Maybe your sources of information were biased. In a
book with the good reputation that yours has, this is unjustly
damaging to the SESAME technology, which after all is the only
supported publicly available Open Systems technology of this
kind outside the USA.
The description is slanted in that it not only criticises
SESAME for being issued with the cryptography effectively
removed ("instead of using real cryptography they use XOR with
a 64-bit key size"), it also criticises SESAME again, and more
severely, for not using the XOR securely ("even worse, they use
XOR in CBC mode..."). Clearly if XOR is used, it is so insecure
that it doesn't matter a jot that the CBC with XOR renders half
the text unencrypted. No one believes that XOR is other than
valueless from a security point of view (we put it in, in
preference to nothing, so that the "crypto" path could at least
be seen to be executed when SESAME is installed for study
purposes), but your implication is that the SESAME project
(naively?) thought that it did provide some level of security.
It must have been obvious to you that the CBC implementation is
intended to be of real use only when DES or another secure
crypto package is put in to replace XOR. The idea of the CBC
was of course just to simulate the way in which DES would be
used.
The description is slanted because it does not similarly
criticise the Kerberos V4 "bones" implementation, which is the
only version of Kerberos legally available outside the USA, and
which not only has no cryptography in it, but also doesn't have
the low level interfaces with which to be able to insert
cryptography easily (by the way, Kerberos V5 isn't legally
available at all outside the USA, bones or no bones, and the
rest of the world is stuck with an outdated V4 in the absence
of SESAME). Like every other publicly available technology,
SESAME has had to conform to government export legislation
(this is not just the French by the way), and to say you are
"unimpressed nonetheless" with our taking out the cryptography
begs the question: what legally acceptable approach would have
impressed? Like MIT with Kerberos, we had no choice.
If you are referring to SESAME with crypto instead of XOR, the
description is inaccurate when it says "authentication in
SESAME is a function on the first block of a message, not on
the entire message....". It is hard to see what you are
referring to here. Perhaps you could clarify. One possibility
is that you are still talking about the XOR placeholder code.
If this is the case, you certainly don't make this clear, and
the reader might be left with the false impression that it is a
fundamental design property of SESAME.
Finally there is the criticism of the use of two UNIX rand
functions for key generation. Once again, this criticism
applies only to the XOR version of the technology, though you
do not say so. Standard DES implementation packages contain
their own secure key generation functionality. However, Serious
SESAME implementors are expected to use such functionality, or
similar, not the placeholder rands that are in the publicly
available version. Perhaps you didn't realise this, and there
is a valid criticism that we should have made it clearer.
So to summarise: There is indeed the problem that the XOR
replacement of DES is insecure, and that any real
implementation, just like for Kerberos outside the USA (though
easier for SESAME), needs to have proper basic cryptographic
functions added. However without criticising the non-USA crypto
free version of Kerberos, you criticise SESAME as being
"seriously flawed in several respects" although all of these
respects are in fact variations on the one single unavoidable
respect of putting in temporary placeholder code to do the
actual cryptography. The reader could easily be left with the
idea that SESAME is an amateurish flawed technology that is not
worth bothering with. Key phrases in your criticism that will
stick in readers' minds are "seriously flawed in several
respects", and "I am unimpressed".
More impartial equivalent text in your Section 24.7 might have
been:
"Because of European cryptographic export regulations,
the version of SESAME that is in the public domain has
had its cryptographic functions removed and replaced by
insecure XOR placeholder code. This is an approach
similar to that taken by the "bones" version of Kerberos
V4, though unlike Kerberos, the SESAME team were able to
leave in the basic cryptographic interfaces so replugging
proper cryptography should be easier. Any serious
implementation of SESAME needs to replace this
placeholder code with secure cryptographic functions."
Not that I want to put words in your mouth :-)!
It would also have be nice to have seen an appraisal of the
functionality of SESAME that surrounds the basic crypto
support, which although it must of course be securely designed,
is not what SESAME is all about.
For your interest, SESAME improvements since V2 have been:
SESAME V3: better privilege attribute management with a wider
range of attribute types, support for strong user
authentication using an asymmetric private key, pure public key
and also hybrid public/symmetric based key distribution with
associated PK infrastructure (i.e. use of extended X.509
certificates, implementations of off-line CAs and on-line
registration authorities and agents), support for PC clients,
implementation of an audit daemon to better protect audit
trails, better protection of cryptographic master keys, and
some bug fixes and general clean up. V3 is available from our
web server:
www.esat.kuleuven.ac.be/cosic/sesame.html
SESAME V4: SESAME V3 had Kerberos V5 code in it, which at the
time of implementation was legal (exported by NIST!). Now the
NSA says it's illegal, so SESAME V4 replaces all that code with
a legal equivalent. SESAME V4 is about to be released.
Neither SESAME V3 nor V4 use CRC32.
I would like to encourage you to read the SESAME Overview and
other documentation from the web server.
I would be grateful if you could respond to these rebuttals of
your criticisms, to say whether you see any merit in them, and,
I hope, for you to agree to you publishing a retraction or
erratum.
Yours sincerely,
Tom Parker
SESAME Architect
ICL Enterprise Technology
END OF LETTER TO SCHNEIER.
For those readers who are interested in finding out more about SESAME
technology, I refer you to the web site identified in the letter.
Since the letter was written, SESAME V4 has been released, and an
Internet draft "The SESAME GSS-API Mechanism" has been produced, and
is available on the usual servers.
Tom Parker
30th July 1996
Jonathan I. Kamens
In article <4tkj8u$dvd$1...@mhafn.production.compuserve.com>, Tom Parker <10032...@CompuServe.COM> writes:
[Mr. Parker posted an article defending SESAME against Schneier's
criticisms of it in "Applied Cryptography" 2nd Ed. I am eliding most
of Parker's article because I wish to respond only to some of the
points he makes about Kerberos. Readers who are interested in the
entire article can find it in sci.crypt or alt.security. I have
directed followups to comp.protocols.kerberos.]
|> The description is slanted because it does not similarly
|> criticise the Kerberos V4 "bones" implementation, which is the
|> only version of Kerberos legally available outside the USA, and
|> which not only has no cryptography in it, but also doesn't have
|> the low level interfaces with which to be able to insert
|> cryptography easily
That is not true. eBones is available legally outside the US and
includes DES encryption.
|> (by the way, Kerberos V5 isn't legally
|> available at all outside the USA, bones or no bones, and the
|> rest of the world is stuck with an outdated V4 in the absence
|> of SESAME).
That isn't true either, unless you really meant to write, "by the way,
SOURCE CODE FOR Kerberos V5 isn't legally available..." At least two
different vendors of Kerberos V5 technology, OpenVision and CyberSafe,
sell Kerberos V5 products outside the US.
--
Jonathan Kamens | OpenVision Technologies, Inc. | j...@cam.ov.com
Thor Lancelot Simon
In article <4tkj8u$dvd$1...@mhafn.production.compuserve.com>,
Tom Parker <10032...@CompuServe.COM> wrote:
[...]
>The description is slanted because it does not similarly
>criticise the Kerberos V4 "bones" implementation, which is the
>only version of Kerberos legally available outside the USA, and
This is demonstrative of an author who either doesn't know what he's talking
about or is deliberately spreading misinformation.
The freely-available "eBones" reimplementation of crypto-enabled Kerberos has
been available for *years*. This also puts the lie to Mr. Parker's implication
that reinserting cryptography in MIT "bones" would be extremely difficult.
Given this, I would be extremely skeptical about the rest of what Mr. Parker
has to say.
--
Thor Lancelot Simon t...@panix.COM
"Gee, if your knee jerks any harder you're going to kick yourself in the head."
-- Barry Sherman