From: Tom Parker <100325.474@CompuServe.COM> Subject: A Defence of SESAME Date: 1996/07/30 Message-ID: <4tkj8u$dvd$1@mhafn.production.compuserve.com> organization: ICL newsgroups: sci.crypt,alt.security 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 t.a.parker@win0199.wins.icl.co.uk