Identity—Integrity—Privacy—Secure Sockets Layer—LDAP authentication —JAAS—The RMI Security Extension—Exercises
Chapter 8 was concerned with permissions granted to code.
This chapter is concerned with two further aspects of security: permissions granted to users, and the security of the network conversation itself. This involves several topics:
the identity of each party to the conversation
the integrity of the message
the privacy of the conversation.
Security concerns the identity of each party to the conversation, in two distinct ways:
authentication
authorization.
We would like each end of a conversation to be able to authenticate itself—prove its identity—to the other end. Ultimately, this has to come down to an exchange of secret information previously known to both ends, or acquired from a mutually trusted third party. Many techniques exist, including:
Authentication in Java relies on the concepts of subject, principal, and credential.
A subject is a set of related information for a single entity such as a person.
A subject has one or more principals, which are really just alternate names for the subject. Examples of principals are: full name, driver's licence number, Social Security number (USA), Tax File number (Australia)—anything which uniquely identifies the subject in some domain. All principals in a subject refer to the same subject.
A subject may also own security-related attributes known as credentials—such as private and public keys, certificates, Kerberos server tickets, and so on. These are stored in the subject in private or public credential sets, depending on whether they are or are not sensitive credentials requiring special protection, such as private cryptographic keys.
Once we know reliably who we are talking to, we want to determine that party's authority—whether they are entitled to send certain messages, make certain requests, and so on. Authorization is a matter of enforcing application-specific policies, based on the other party's identity, or some aspect of it: for example, their department, or their physical address.
We are next concerned with assuring the integrity of each message received—assuring ourselves that the received message:
has been completely and correctly delivered by the transport
has not been tampered with in transit
has not been completely forged by a third party.
Message integrity assures the receiver that it has a complete message from an identified and authenticated source.
The technique commonly used to assure message integrity is the message digest.
A message digest is a cryptographically secure annotation delivered with the message. It is formed by a computation over the original message contents. The receiving end can recompute the digest and compare it with the transmitted digest: if they are equal, the message is intact and unforged.
Secret information, not part of the message itself, is used to compute the digest. If you don't know the secret, you can't compute a message digest acceptable to someone who does know the secret.
Privacy is the prevention of eavesdropping on the conversation.
Is there any inherent privacy in RMI? An RMI transmission is encoded by at least all the protocol layers shown in Figure 16.1.
On top of all this, there is usually some kind of application protocol, consisting at least of the class definitions of the objects being transmitted.
It may be thought that a certain level of privacy is assured in RMI by the sheer number of protocols involved. However, IP, TCP, the Java Object Serialization protocol, and JRMP are all published protocols. Stripping out the IP and TCP data is a relatively easy exercise, already implemented in network analysers (“sniffers”) and TCP/IP traffic-analysis programs. An eavesdropper would find it quite easy to understand large amounts of plain text, and reasonably possible to decipher application-specific data with some knowledge of the application data structures. This task is made easier by the fact that RMI annotates serialized class information with a codebase, allowing the eavesdropper possible access to the class files associated with the data.
For these reasons, eavesdropping over RMI is actually easier than with some other communications systems. RMI conversations which require genuine privacy must be encrypted.
The purpose of encryption is to make it infeasibly difficult to eavesdrop on the data in transit.
Without going into all the gory details of various encryption techniques, the data to be transmitted is first encrypted using a secret key. This key does not form part of the message; instead, it has been separately agreed to by the parties to the communication. The encryption technique completely obfuscates the message. The original message can be recovered by decrypting with the same key, or, in public/private key systems, with the private key, after the message was encrypted with the public key.
The key is chosen so that guessing it, or trying to crack the message by brute-force enumeration techniques, is computationally infeasible—would take longer than the lifetime of interest of the message. The degree of security of the encryption is related directly to the length of the key: this is why there are 40-bit keys, 56-bit keys, and so on up to (presently) 128-bit keys. The longer the key, the better[1]
Secure Sockets Layer (SSL) is the name of a family of protocols layered over TCP and the Sockets API which provides authentication, integrity, and encryption services.[2] SSL provides connection security which has three basic properties:
privacy: encryption is used after an initial handshake to define a secret key
the peer's identity can be authenticated
reliable: the transport includes a message integrity check.
Implementations of SSL for Java have been available for some time from third-party vendors. In 1999 Sun introduced the Java Secure Sockets Extension (JSSE), which supports SSL 3.0, TLS 1.0, WTLS, and related protocols.[3]
SSL can be integrated into RMI so that RMI clients and servers communicate over one of the SSL protocols. This is done via the socket factory facility described in Chapter 11. JSSE includes SSLSocketFactory and SSLServerSocketFactory classes. These classes are not implementations of RMIClientSocketFactory and RMIServerSocketFactory respectively, so a little bit of programming “glue” is required to adapt the socket factories to the required RMI socket factory interfaces. This fairly trivial exercise in the adapter pattern is left to the reader.
The JSSE package also includes a secure-HTTP URL handler for the HTTPS protocol.
It may be wondered whether SSL has anything to do with RMI/HTTP tunnelling. The answer is “no”: the http: tunnelling URL built by the RMI transport is hard-wired inside the default socket factory, and cannot be altered to use the https protocol.
The SSL socket factories create SSLSockets and SSLServerSockets; these extend Socket and ServerSocket respectively. These extended socket classes provide two facilities:
Both the client and the server can enable specific “cipher suites”. An SSL cipher suite implements a policy about whether, and how strongly, the other end must authenticate itself, and about how strongly the data traffic is encrypted. JSSE is provided with several cipher suites, depending on your location.[4]An SSL session can only be established if an enabled “cipher suite” common to both ends can be found. The default configuration supports a number of cipher suites, but does not enable them all.
Both client and server sockets can access the underlying SSL session. This facility can be used to maintain session state, or to terminate an entire SSL session—forcing the other end to re-authenticate itself on the next use of the connection.
It is possible to set up LDAP directories to require authentication before a client can access them. This can be used as a broadly-based form of access control to RMI servers. If the initial server to be looked up is in a directory requiring client authentication, that client is implicitly authenticated to all RMI servers reachable from that server. This technique is usually used in J2EE (Enterprise Edition)-based applications. Consult the JNDI documentation for the LDAP provider for further information.
The Java Authentication and Authorization Service (JAAS) architecture, introduced to supplement Java 2 JDK 1.3, addresses the issues of authentication and authorization, providing a common framework into which various kinds of security policies and implementations can be integrated.
The JAAS framework provides for:
establishing and verifying a user's identity
performing security-provider-defined logins
temporarily assuming an acquired identity, to perform an action on behalf of another.
The RMI Security Extension specifies a security layer for RMI,[5] built on top of the JAAS architecture. It addresses all four of the proposed security issues of this chapter: authentication, authorization, integrity, and privacy, and adds the further facility of delegation: a client may delegate its identity (its JAAS subject) to the server, allowing the server to securely impersonate the client while performing local or remote activity on its behalf.
The RMI Security Extension is aimed not only at RMI, but also at all kinds of remote object access involving client access via a proxy. (Remember that in RMI, client access is via a remote stub, which is a proxy to the remote service.) Most notably this includes Jini.
At the time of writing, the specification was still provisional, and no implementation was available for experimentation. Our discussion is limited to describing the major concepts of the RMI Security Extension: we do not discuss specifics of the API, which are subject to change between the draft and eventual release. We have not verified or tested any of the features described.
The RMI Security Extension is based on the concept of security constraints: requirements or preferences expressed by clients and servers about the security level of a specific RMI conversation as a whole, or about one or more individual remote methods in the conversation.
Constraints supported by the RMI Security Extension include:
conversational integrity (YES or NO)
conversational confidentiality (YES or NO)
authenticate the client (YES or NO)
authenticate the server (YES or NO)
delegate the client identity to the server (YES or NO)
time limits on the duration of any delegation
minimal and maximal sets of principals as which the client must authenticate itself, if it does so at all, and associated principal types (implementation classes)
minimal sets of principals as which the server must authenticate itself, if it does so at all.
The client and server constraints are aggregated. Required constraints override preferred constraints; when two preferred constraints conflict, it is arbitrary which one is retained. The resulting set of constraints is used to select an endpoint factory for the conversation or an individual method call: a factory will be chosen which supports all the constraints in the aggregated set. (An endpoint is an abstraction of a ServerSocket; a client endpoint is an abstraction of a Socket; and an endpoint factory is an abstraction of a socket factory. These concepts are intended to remove explicit dependencies on TCP/IP.)
The Security Extension introduces two helper classes for writing secure unicast servers and secure activatable servers. An RMI server can be exported as a secure server by calling an exportObject method provided by one of these classes. Both classes provide corresponding unexportObject methods.
When a secure server is exported, a “secure export descriptor” object can be provided. This object defines, inter alia, the default constraints and method-specific constraints, if any, for the server. These method constraints are also made available as the “server constraints” of the secure stub exported by the server. If none are available, the default constraints are used.
The secure export descriptor object may also contain an array of endpoint factories, each of which is associated with a set of supported constraints. This array indirectly associates endpoint factories, via constraints, with methods, so that some methods may be unconstrained while others can only be executed via a sufficiently constrained endpoint factory. Some of this information is exported via the secure stub, so that the client can automatically be supplied with an appropriately secure client endpoint factory for each method call.
In this way, different methods in a remote object can be defined to require different levels of connection security, which may lead to different endpoint factories being employed for each method.
A secure server can obtain its client's subject. If the client was not authenticated, the result is null, otherwise a javax.security.auth.Subject is returned. This can be used by the server in a number of ways, of which perhaps the most significant is “secure impersonation” or delegation. The client can delegate to the server the authority to impersonate it by means of a delegation constraint. A server operating under a delegation constraint can choose to securely impersonate that client when performing outbound secure calls, or receiving other inbound secure calls, by means of the Subject.doAs operation.
The server can also obtain the security constraints for the current remote call.
The Extension supports pre- and post-invocation access control, and control over parameter unmarshalling and return value marshalling.
An activatable secure server has all the new features defined above. In addition, when exported, it defines a set of security constraints for the activator to apply when checking client access prior to activating the object, and it may declare that it implements an interface for activator security.
A secure client is one which receives a secure stub—it is a client of a secure server. A secure stub implements an interface which lets the client get the server constraints, and to get and set the client constraints. A client may operate under the client constraints supplied by the server in the secure stub, or it may replace them with its own.
If the secure server is activatable, an additional step occurs at the client, to ensure that the activator constraints of the server and its client security constraints can both be obtained without an exception being thrown, and that they are the same. This process establishes mutual trust, first between client and the Activator, then between the Activator and server, thus transitively establishing trust between client and server:
C trusts A + A trusts S ⇒ C trusts S
A secure client or server can use the java.rmi.Security.doConstrained method to enter a secure code section, which extends for the life of the run method of the PrivilegedAction object supplied as the first parameter. The security constraints supplied as the second parameter are applied to all secure remote calls executed in the section.
1: | Show how to implement SSL into RMI, by writing adapter classes, say |
[1] A comprehensible account of encryption and key-distribution techniques is given in Singh. The Code Book, Chapter 6.
[2] Frier, Karlton, and Kocher, The SSL 3.0 Protocol. See also Wagner and Schneier, Analysis of the SSL 3.0 Protocol.
[3] Transport Layer Security (TLS), a semi-inter-operable superset of SSL 3.0, is specified in IETF RFC 2264.
[4] Because the USA places restrictions on the export of cryptographic software.
[5] Java RMI Security Extension Early Look Draft 3