Charlie Kaufman: Security Status Interview by Betsy Kosheff

Level: All Works with: All Updated: 01-Oct-97

Meet Charlie Kaufman, Notes security expert. He's the guy who figured out how to cope with U.S. government export controls on 64-bit cryptographic algorithms (like Notes has). He's co-authored a comprehensive book on network security, and helped invent many of the security features for which Notes is famous. Now, as Security Project Leader, he's shining his light on Notes 5.0, with planned support for native X.509 certificates, S/MIME, and some cool new tools to ease security administration.

You're the one who figured out how to make Notes exportable, right?
Well, I figured out how to make the exportable edition nearly as secure as the North American edition. Notes has always been exportable, but before Release 4, it did so by offering weaker encryption in the exportable edition, and many customers considered the security of that approach inadequate.

What was involved?
I led the Release 4 team in implementing something we call differential workfactor cryptography. U.S. export controls on cryptography basically say that we can't export anything they can't break. So, we had to go to great lengths to satisfy export criteria, while maintaining Notes' own 64-bit key scheme. They wanted us to implement a backdoor fix so the government could get in, but we didn't much like that idea, so we came up with an interesting alternative. We use 64-bits within the United States, which is considered fairly strong. In the exportable Edition, we also use 64-bits, but make 24 of those bits available to the U.S. government.

So, for the U.S. government, it takes a 40-bit workfactor to break in, but for everybody else, it still takes a 64-bit workfactor. This is sort of the best of both worlds -- it doesn't make the product any less secure against the U.S. government, but it makes it substantially more secure against all other attackers. We still wish the U.S. government would let us do better, but this solution satisfies more customers than either of the other available alternatives.

Does anyone else have this type of security solution?
Not that I know of, at least, no other company has a solution for exporting strong encryption that is both legal and available to every type of business without a backdoor that makes government access trivial. The only other legally sanctioned scheme is limited to use by banks. So, no other U.S. vendor can compete with us in this respect.



What advice do you have for other companies looking to export their systems?
I would encourage other companies to look at similar approaches, though I know some other companies have tried and failed, and I don't know of anyone who has succeeded in getting approval for such a scheme. At present, the U.S. government doesn't appear to be willing to approve any radically different scheme unless the scheme's use is restricted to specific business sectors, such as banking, or it implements "key recovery," where the government can get access to data on demand. But the laws concerning export are very fluid right now -- the rules seem to change almost weekly. Companies need to take a two-pronged approach of trying to negotiate the strongest encryption they can get from export administration, while continuing to lobby for liberalization of the laws.

What other Notes security features do you think are noteworthy?
Well, Notes/Domino just has a whole list of authentication, authorization and encryption features you don't see in other products. From the beginning, it has had the ability to encrypt client-server connections, e-mail, and stored documents. While encryption of client-server connections is now fairly standard in competitive products, e-mail encryption is only beginning to emerge, and encryption of documents in databases is still years away. Our public key infrastructure is well developed and years of deployment have given us the experience to solve problems our competitors don't even know they have yet. So, the recent enhancements have been built on top of a very strong base.

For example, in Notes Release 4, you got the ability to protect an ID with multiple passwords. So, if you have some administrator walk off with the certifier ID, no single person can open it. You might have five people with access to the certifier ID, two of whom have to work together to open it.

Generally, when most people think of security, they think of encryption. But flexibility and comprehensibility in defining groups and managing access to resources are often the bigger challenges. The ability that Notes offers to control access at the level of servers, databases, records, and fields gives enormous power for trading off flexibility and complexity.

What's the big security addition in Notes 4.6?
SSL (Secure Sockets Layer) version 3 support for additional Internet protocols. In Notes 4.5, the big addition was support for SSL for the HTTP protocol, but in 4.6, SSL is also supported for POP3, NNTP, LDAP and IMAP.

In 4.6, we support SSL V3, where the big change is the ability for the server to authenticate the client. In SSL V2, the client cryptographically authenticates the server, and then sends a user name and password over the encrypted channel for the server to authenticate the user. SSL V2 is not really as secure as the certificate-based approach, which Notes and Domino have always used before Internet protocols.

What's the focus of your 5.0 security efforts?
The biggest single ongoing project is continuing to integrate the security infrastructure of Notes with the security infrastructure of the Internet. A big step in V5 will be better integration of Notes and Internet certificates. A certificate is just a signed statement of someone's public key, but the Internet has grown up with a different syntax than Notes, so one of the main things we're doing with 5.0 involves converting Notes over to x.509 v.3 certificates.

Sounds tricky. What's involved?
Converting to a new syntax is the easy part. But it's not just the certificates, but the styles of names that are different. The names in Notes consist of items like an optional country, an organization, and a common name, while on the 'Net, different types of components are used. So, making these certificates mutually useful is quite a challenge.

I thought Notes/Domino already supported X.509 v. 3?
We do when you're coming in via a Web protocol, but what's happening today is that a user who has both a Notes client and a browser is ending up with two sets of credentials and two different names. And that's an administrative burden because you have to create the certificates in two separate administrative steps. We want to unify those, so that a single administrative action creates the user account for all purposes.

What else is coming in Notes/Domino 5.0?
Another of the big security projects we're working on is the ability to more easily change certifier keys.

For both Notes/Domino and for our competitors' systems, certifiers use their keys to generate certificates, but if someone, say a fired administrator, steals the certifier key, it's extremely difficult to create a new certifier and update all the existing certificates so the thief can't break into the system. We're trying to make that recovery process more automated and smooth. For an interim period, you need to have the ability to have two certifier keys, either of which will be trusted. And you do that while you're in the process of updating the certifier keys to trust a new one. So, first, you need to have everybody trust a new certifier, then get new certificates from the new certifier, and then stop trusting the old certifier. And after three steps, you're safe from the bad guy. Today, we have a collection of administrative procedures for dealing with the situation, but they always involve more work and less security than anyone would like. With certifier IDs protected with multiple passwords, we've made it less likely that someone will steal the certifier if customers are careful. This is the other half of the solution, which makes it so that if someone does steal the certifier, we can make recovery easier.

What has been your experience in developing support for S/MIME?
S/MIME (Secure Multipurpose Internet Mail Extension) is basically the Internet's version of secure mail and has essentially the same functionality as Notes encrypted mail, but it's different. There are two hard parts to that conversion -- one is to convert the security, and the other is to convert the syntax of the message from the format that Notes historically used, which is Rich Text, to MIME, which accomplishes much the same thing.

One of the hardest problems is backwards compatibility because, how do you know what the capabilities of the recipient are, in terms of the format he or she wants to accept? One way is to look at how others are doing it and how they find out what the capabilities of the recipient are, and then use the same techniques. If you're sending an encrypted message, you can post the information about however you learned the person's public key, and then put the format information in the same place so it can be retrieved as well. It's going to be tricky to get this to be as easy to use as it was in the good old days when we controlled the sending and the receiving software.

You can also interoperate with mail users that use MIME today by having gateways translate; unfortunately, when you send mail in encrypted form, you can't use a gateway because the data can only be transformed when it's decrypted and it's encrypted with a key the gateway does not have.

Given the current brouhaha over standardization, do you think S/MIME is dead?
No, but it's certainly in a state of flux. The IETF (Internet Engineering Task Force) has been trying to come up with a standard for encrypted mail forever -- I was involved with the committee back in 1988 and they were well into it back then. What they've been hung up on is which cryptographic algorithm to specify and how to set up a hierarchy of certificates. This has been complicated by the fact that the cryptographic algorithms have been patented and the patent holders wanted to have a say in how all this stuff works. The first standard was called PEM, then there was a successor called MOSS, and neither one of them went anywhere. So, RSA Data Security has developed their own encryption format called S/MIME, and they've signed on a number of commercial partners. It's been developed as a de facto standard and people have started to ship it, as we plan to. The IETF may or may not ever standardize it, and this will have an influence on its success, but the real road to success on the Internet is compatible implementations from multiple vendors.

Does S/MIME work?
Well, there are interoperability demonstrations going on right now, although it remains to be seen whether they will work outside the confines of the carefully crafted scenarios of the demo. The wonder of electronic mail is that I can send mail to someone on the other side of the world, and all I need to know is his name. But some of these cryptographic schemes only work if there's a prior agreement between pairs of people. I don't know whether S/MIME actually works today without excessive amounts of administrative overhead, but this certainly is the goal for all of us. We're not there yet, but things are getting better everyday. Right now, we're planning to include S/MIME in Notes 5.0, so we'll work with Netscape and Microsoft and whoever else implements it to make sure interoperability is as good as it can be.

Why is the IETF resisting S/MIME?
The IETF likes to develop designs by committee and then standardize them, and they're generally not amenable to having someone propose something and have them bless it. SSL, which was developed by Netscape, is largely viewed as a sort of victory over this mentality because they are probably going to standardize it, albeit with a few changes, including changing the name from SSL to TLS. But even now, there are proposed additional changes that could make it incompatible with everything that's out there.

What's really going on?
The motivation has to do with patents. This September, the first major patent on a public key cryptographic algorithm expired -- the Diffie-Hellman key agreement patent. RSA's competing patent expires on Sept. 20, 2000. Historically, the terms to license RSA have been and continue to be expensive, whereas the terms to license Diffie-Hellman are now free. So, the IETF wants to standardize all the protocols on the Diffie-Hellman suite and disenfranchise the RSA patent holders. This means that S/MIME and SSL, which both depend on the RSA algorithm, would be no longer politically acceptable.

So what should developers do?
The bottom line is that it's going to slow things down. But people don't really care what blessed standards are out there. What they care about is interoperability with what other vendors are selling, and S/MIME and SSL support is going to be shipped by vendors. So, this lack of an IETF blessing is not going to have much of an impact on whether they succeed.

Will you support the new e-mail security spec, Open PGP?
We're going to see if it gets a sufficient following, and if it does, we'll support it. But I would be more inclined to develop something that interoperates with the already deployed version of PGP, because the newer Open PGP is years away. And the big question is whether it gathers enough momentum before its reason for being goes away when the RSA patent expires in 2000.

What's the difference between PGP and Open PGP?
The IETF has apparently abandoned S/MIME and said it will go with a new mail protocol called Open PGP. PGP (Pretty Good Privacy) is an Internet encrypted mail not developed by a company, but by one pioneering individual named Phil Zimmerman, who developed the code and published it as freeware on the Internet (It subsequently developed a following and was enhanced by lots of engineers, mostly volunteers). Its certificate structure is a very loose one, in which, instead of having authorities issue certificates to individuals, anyone can issue a certificate to anyone else, and then if you can find someone you trust who has signed off on it, you can learn someone's key. On the one hand, it inherently doesn't scale very well; on the other hand, it supposedly has over 20 million users. That would make it the biggest public key infrastructure in the world, followed by Notes.

But PGP also uses the RSA algorithm, just like S/MIME, SSL, and Notes, so the IETF is not going to standardize it. It will standardize on something new called Open PGP, which takes its non-cryptographic syntax from the PGP implementation, rather than the one that underlies S/MIME, and then uses the Diffie-Hellman suite. So, it's non-interoperable with this enormous installed base of PGP users.

Are you going to support Diffie-Hellman?
No, we currently have no plans to convert our infrastructure over to Diffie-Hellman. If the IETF gets major vendors to deploy it, then we will, but I'm highly suspicious of their ability to do that.

Where do you think this will all end up?
My belief is that this whole effort is well intentioned, but it's doomed to failure. And the reason is because the RSA patent runs out in 2000. By the time Open PGP gets any substantial deployment, the patents will have expired and the advantage of using these alternative algorithms will have gone away.

Why didn't Iris offer up the Notes protocol as a standard mail protocol?
We considered it. But the problem is that the Notes protocols are quite complex. They evolved from writing the code rather than writing a spec. What was simple to do in code is not necessarily simple to specify. As a result, I believe that if we tried to actually write a spec for what the Notes protocol looks like, it would be unacceptably complex for a standards committee.

If we had wanted to design Notes so that it would be easy to submit for standardization, we could have done that. We might have been in better shape with the standards, but we would have been less feature rich. This has always been the big trade off. Proprietary approaches can always do much better stuff in solving people's problems -- a great example is the decision we made to have 64-bit strong against all attackers but 40-bit strong against the U.S. government. That's the kind of deal an organization can have with the government, but a standards committee really can't.

Is it frustrating to find that so much of your work involves reworking existing Notes capabilities -- things Notes already does so much better than anything else -- in order to interoperate with the standards?
Yes, but it's what the marketplace demands. Another part of the effort is to make the standards better, but when you put different pieces together to interoperate, you're going to lose functionality when you make that conversion. Sometimes it's like we have to work really hard every day to make the product worse. But we all know it's the right thing to do.

People seem to have relaxed about security issues on the Web over the past year, or at least, that's what we hear in the press -- do you agree?
It does seem that way and I don't think that's because technically anything has gotten much better. I think the security problems posed by the Web were not nearly as bad as people thought they were, and I don't think things are nearly as good as people seem to think they are now.

It's true that people troll the Internet and break into routers and pick up traffic. And one of the things people pick up that we all find very scary is credit card numbers. But just because someone can learn your number, it doesn't mean that they can do much. It's somewhat the same as tapping telephones or picking a receipt out of the trash. You can order something, but then you have to give them an address. People want to be able to order software anonymously, but there are a number of things that have to happen for that to be actually workable. If the card owner says they didn't make the charge, then it's up the vendor to go after the customer for the money. If the purchase is anonymous, the fraud rate is likely to be very high. It's going to take advances in both technology and in the legal system before the dream of software sales over the Web really takes off. But all of this is not conceptually different than all the problems that have occurred with respect to fraud before the Internet.

Do you think Domino will be a serious contender as a platform for commerce?
Yes, because in addition to being a highly secure system, it's a very powerful server structure for being able to handle complicated transactions. In commerce, the problem of securely getting the actual credit card number is really just a tiny piece of the problem. The real problem is how do you structure your sales catalogue, and so on, so that people will be attracted to going to the Web to look at your merchandise. Domino is very good at putting together such things, and it's very attractive to have the last stage of electronic commerce -- securely accepting the transaction -- be in the same place.

BIOGRAPHY
Charlie Kaufman joined Iris three years ago and is Project Leader and Security Architect for the Notes/Domino 5.0 security effort. He is a member of a National Research Council expert panel on computer system trustworthiness, participates in a number of IETF standards efforts, and is chair of the Web Transaction Security working group. Additionally, he is co-author of "Network Security: Private Communication in a Public World," published by Prentice Hall.

Previously, Charlie was Network Security Architect for Digital Equipment Corporation. He holds more than 20 patents in the fields of computer security and computer networking, as well as a bachelor's degree from Bates College and a master's degree from Dartmouth College, both in mathematics.

Copyright 1997 Iris Associates, Inc. All rights reserved.