A Conversation with Bob Scheifler, Part I

Many potential applications of Jini require network security. Although various third parties have made proprietary security extensions to Jini, until now the only security available to users of the standard Jini release is the security infrastructure of the Java platform. The Jini Community's Davis project is about to change that. Bob Scheifler is leading the development of the next release of Jini, in which security is the central concern, as part of the Davis project. On Friday, April 12, 2002 Bill Venners visited the Sun Microsystems campus in Burlington, Massachusettes and interviewed Bob Scheifler, Sun Distinguished Engineer and architect in the Jini Group. In this first installment of the interview, Scheifler discusses the need for security in Jini and the special security considerations of dynamically downloaded code.

Bill Venners: What is the need for security in Jini? What problem you are trying to solve?

Bob Scheifler: The basic problem is to fill in the blanks from what the Java platform provides for security today. If you look at the Java platform, it has built-in security mechanisms for protection against code running in your VM. But Java, RMI, and Jini don't have any standardized concepts for security as they apply to network communication.

If I am a Jini client, and I talk to you as a Jini service, there are standard notions of network security that should come into play. The basic notions of network security, authentication, confidentially, and integrity are not new with Jini. These are standard network security concepts. And Jini, since it uses the network, ought to have some way of supporting those standard concepts.

Authentication, Integrity, and Confidentiality

Let's start with authentication. When I make a call to a service that I think should be run by Bill Venners, I want to make sure the service is actually being run by Bill Venners. If I talk to my banking service, I want to make sure it is Citicorp or whatever my bank is, rather than Thieves Are Us or Fly By Night, Inc. Likewise, the bank wants me as a client to prove who I am. When I want to access my bank account, the bank wants to know it actually is me so it can let me access my bank account but not your bank account.

It is really mutual authentication. We both want to know each other's identity, though maybe for slightly different reasons. You as a service want to know my identity as a client to make authorization or access control decisions, to decide what I am and am not allowed to do. As a client, I want to know your identity as a service to make sure I am really talking to you.

Bill Venners: Let me make sure I understand the difference between authentication and authorization. Authentication verifies you are who you say you are. Once I know who you are, authorization is how I specify what I allow you to do. Is that right?

Bob Scheifler: Yes, exactly.

Another standard network security notion is integrity. Integrity means that while we have this conversation, we want to make sure no evil third party on the network corrupts our messages. So that when I say, "Transfer $100 to Bill," somebody else can't interject and say, "Transfer the $100 to Joe," or "Transfer $1,000 to Bill." Integrity is a mechanism that allows us to find out if any third party tries to corrupt our conversation.

Lastly, confidentiality simply means the two of us don't want third parties to spy on our conversation. Confidentiality allows us to have a private conversation. Other people might know about our conversation, but they don't know what the conversation is about.

At the highest level, we want Jini security to deal with those basic notions of network security. We want to support mutual authentication for authorization or access control decisions. We want to support confidentiality and integrity. Those are not novel ideas. This is standard network security as it applies to Jini. What is special about Jini relative to network security is dynamically downloaded code. That's where the complexity of understanding how to do network security in Jini comes up.

Mutual Authorization

Bill Venners: What particular problems arise in the context of dynamically downloaded code?

Bob Scheifler: There are three special ramifications with respect to dynamically downloaded code. One is that we have a mutual authorization problem—not just a mutual authentication problem but a mutual authorization problem. In normal network security—where I am a client again talking to you as a service—once I have authenticated to you, you need to make some access control decisions. Am I allowed to access this bank account or not? That is the standard authorization problem. You as a service must decide what I as a client am allowed to do.

With dynamically downloaded code, I as a client also have an authorization problem now because you dynamically downloaded code to me when you sent me your service proxy. So I as a client must decide what that dynamically downloaded code can do next. You might not think of that as an authorization problem, but that is essentially what it is. The security policy I run grants code permission to do something or to not do something—that is access control. That is an authorization decision. I decide what I will let your dynamically downloaded code do in my address space on my behalf.

Client-side authorization decisions are new with Jini because in traditional systems with no dynamically downloaded code I don't have to worry about that problem. Usually, I trust all the code I run when I talk to you. I don't want to have to worry about authentication of my code. I just trust it.

Proxy Trust

Bob Scheifler: The second ramification of dynamically downloaded code is the question of proxy trust. I have this downloaded code for the proxy, and I talk to you, the service, through that code. Somehow I decide to trust that code to do the right thing. For a simple example, say I download a proxy for you from somewhere, and I want to make a call through that proxy. I want to tell it, "Make sure the other end authenticates as Bill Venners." How do I know the proxy isn't simply going to lie and say, "Oh, yeah, sure, Bill's at the other end"? When I say, "Please transfer a hundred dollars," how do I know it won't say, "Oh, yeah, I transferred it," but transfer a thousand dollars instead?

Once I dynamically download code, and I perform any operation that has any sensitivity or liability—anything in the real world—I will be concerned whether I actually trust that code. Do I trust the proxy to carry out my requests and operate as I expect it to operate? We have to explicitly decide we trust the proxy in order to use it.

Object Integrity

Bob Scheifler: The third special ramification of dynamically downloaded code involves object integrity. The usual semantics for network communications is data integrity. If we send messages back and forth, integrity means those individual messages do not get corrupted. If I have a TCP connection and it has a bidirectional stream, integrity means the data in that stream does not become corrupted. When you deal with Jini and the notion of dynamically downloaded code, you do not just deal with data. You deal with objects. Objects have data and code, both of which require integrity.

In Jini, code is sent out-of-band, or separate from the data. Clients and services exchange messages that include objects. When you send objects back and forth, the data for the object is sent in-band as part of the message. The code is not. Instead of sending class files as part of the message, you send URLs that indicate where you can get the code if you don't have it. The URL is part of the in-band data. The actual code that we might download asynchronously comes out-of-band. We have to worry about the integrity of that code as well.

Bill Venners: You mean the data integrity of the class files?

Bob Scheifler: You worry about whether I received the code you sent. If I have good data, but it is wrapped around a class file that is bad, then I have nothing. The total integrity of the object is what matters. It doesn't matter if I have good data if I have bad classes. And it doesn't matter if I have good classes if I have bad data. I need both good data and good code. That is the third aspect of downloaded code we need to deal with.

Resources

The Jini Community, the central site for signers of the Jini Sun Community Source Licence to interact:
http://www.jini.org

To get involved in the Davis project, in which Jini security is being defined, go to:
http://davis.jini.org/

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.