I’m progressing through the Erlang-related literature looking for everything relevant to Security. Today I have some comments about Joe Armstrong’s paper “Getting Erlang to talk to the outside world,” published in 2002.
You can find it here: http://www.erlang.se/workshop/2002/Armstrong.pdf . There are also slides from a talk given by Armstrong the same year (here: http://www.sics.se/~joe/talks/pittsburgh_2002_ubf.pdf ) and a more recent presentation by J. W. Norton and S. L. Fritchie in 2009 (http://www.erlang-factory.com/upload/presentations/180/ErlangUserConference2009-NortonandFritchie.pdf ) . Norton and others maintain and develop Armstrong’s UBF communication code at GitHub: https://github.com/ubf/ubf .
All these references are necessary, because Armstrong’s proposal seems to be very well founded and technically correct. It is not only adapted or native to Erlang and in fact addresses many problems with the current standards for systems communications and messaging.
Without detracting from these positive aspects, though, I want to show how at least the original paper by Armstrong provided an incomplete solution to the inter-process and inter-domain communication problem by leaving aside (as is normal in engineering endeavours) any Security considerations. This complements my perception that also current implementations of UBF don’t address Security concerns. For clarity let’s state here that by Security at this level I mean inter-process (or client-server) security capabilities at session level.
The Erlang specialists will perhaps say that the goal of UBF and its implementations is not Security but just manageable, precise communication between programs, platforms and processes. While I agree that this is a very valid goal, nevertheless what follows should stand at least as a suggestion for future developments.
Turning to Armstrong’s original paper, we immediately have a sense of the scope and the limitation of his proposal. “Getting Erlang to talk to the outside world,” seems clearly Erlang focused (to which I have no objection) but also indicates the underlying assumption that “communication” can be reduced to computational intelligibility.
Armstrong is obviously right in providing a way to “build distributed application where Erlang is one of a number of communicating components.” And he is also right in assuming “that these components interact by exchanging messages.” He therefore proposes a well-thought mechanisms for data transport which has numerous advantages of simplicity and resiliency. Armstrong’s focus on high performing, concurrent and resilient systems is evident in this work.
But the blind spot becomes clear if we understand that “real life” interaction, even between machines is not composed of messaging interaction only. In fact, the more general goal of interaction –either human or mechanical- is articulated around talking *and* not-talking to the outside world. While engineering goals in terms of performance and efficiency can be addressed in terms of the “positive” side or “talking,” Security goals will need to integrate both sides (i.e. “talking” and “not-talking”).
It is at this level (which encompasses the engineering side but is not limited to it) that we understand where the gap is: The UBF approach does not offer a solution for session types, session management and access control. Note that it is not the case that the protocol itself does not “allow” this. In fact, session security –if my reading is correct– can be built “on top” of UBF by providing “session contracts” or “contract definitions” which represent security considerations.
Armstrong’s paper (3. Our Architecture) clearly shows a qualitative understanding of the problem by saying: “Our architecture… shows a number of communicating components. The components are assumed to be black boxes., at any particular time a component might behave as a client or as a server. Between the components we place an entity which we call a contract checker […] the contract checker checks the legality of the flow of messages between the components. […] The contract checker is parametrises with a contract that specifies the ordering and types of the allowed message sequences between the client and the server.”
If by “message sequences” we mean also “message types” and if we expand the notion of “contract” to include “session types” then we have a complete base for the implementation of Security with and within the UBF. If, contrariwise, “message sequence” is understood as a pattern without a context (I mean a Security context), then we remain within purely performance-orientated goals.
In the section titled 5.2 Compound Types, Armstrong gives even more tools to whoever would want to implement Security capabilities, with the possibility of building structures and lists to represent “compound objects.” This at least would allow an implementer to define a session as an instance of an “object.”
A good sense of the philosophical background of UBF is seen in section 6, where Armstrong writes: “Central to UBF is the idea of a contract. The contract regulates the set of legal conversations that can take place between a client and a server. A software component… is placed between a client and a server and it checks that all interactions between the client and server are legal. the contract is written using types – the contract says in a formal language something line: ‘if I am in state S and you send me a message of type T1 then I will reply with a message type T2 and move to state S1, or I will reply with a message of type T3 and move to state S2… etc.’ The contract checker dynamically checks that both sides involved in a transaction obey the contract.”
If in the previous text we substitute the term “secure” for the term “legal.” we get a very good idea of what can be achieved. In this case the “contract checker” implements a security policy check (Policy Enforcement Point) and represents the principle of “white listing” in a flow of messages. Now, enforcing a while list leads necessarily to “not talking,” i.e. to the negative side of communication. Where either of the parties in a connection stop the interaction and perhaps issue an error message and other security-related actions.
This would close the circle, by providing a protocol of wider applicability and with more power to address the whole range of states possible in process-to-process or system-to-system communication. By this I mean that a protocol or a language become notably more powerful when they are able to represent not only the states of successful exchange (“Mitteilung”) but also the states of failure. When they enable “talking” and “not talking.” When they enable performance *and* security too.
Nothing of the above is meant to diminish the interest or value of the UBF protocol, and should be seen only as part of my on-going search for the originality and the fundamental differences that mark out Erlang as programing language and platform.
(See also Joe Armstrong’s page at SICS : http://www.sics.se/~joe/ )