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

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