Oi! Not encrypting RPC traffic? IETF bods would like to change that

An Internet Engineering Task Force group has turned its attention to how Remote Procedure Calls (RPC) travel over the internet, and decided a bit of (easy) encryption is in order.

RPC hasn't been updated in more than a decade, and while an attempt was made to bestow encryption upon it in 2016 (in RFC 7861, RPCSEC), take-up is low.

That's a problem, because even a cursory search turns up dozens of ways to attack RPC, and in the Windows world, RPC implementations are common across all platforms. For example, this vulnerability alone, which landed in April 2018, affected everything back to Windows XP.

Putting RPC behind a wall of encryption would improve more than privacy – it also helps protect the service itself, by removing its direct exposure to the Internet.

So Trond Myklebust (chief Linux kernel maintainer for the Networked File System, NFS) and Charles Lever, Oracle's Linux kernel architect, are having another shot at protecting RPC.

In this Internet-Draft, Myklebust and Lever said the issues that hampered RFC 7861 were: it was relatively difficult to keep per-host costs under control; it left some parts of the RFC header in clear text; it could consume host CPU resources; and was challenging if host identity management and user identity management were in different security domains.

We need to go deeper: Meltdown and Spectre flaws will force security further down the stack

READ MORE

Their alternative is to use a TLS mechanism that “can protect the privacy of each RPC connection transparently to RPC and Upper Layer protocols”.

TLS, they argue, would not only make it easier to develop encrypted RPC, because it would remove overheads like identifying hosts to a trust authority, generating additional keys, or provisioning a secured tunnel for the RCP traffic.

Transport-layer encryption also leaves the upper layer protocol intact, and encryption/decryption can be offloaded to hardware, so CPUs don't have to encrypt or decrypt “large RPC arguments and results”.

The basic unit of operation for RPC over TLS is an authentication flavour called AUTH_TLS, which quite simply indicates whether a server supports encryption.

A server that hasn't implemented TLS will respond with an authentication error, or responds without the STARTTLS string, the client knows it's not supported; otherwise, it will initiate TLS negotiation.

Even users of RPC-over-RDMA are protected, the document notes, because it's a higher-level protocol than TLS.

For environments where other authentication mechanisms have already been deployed, the draft said, they can be left in place and TLS used solely to encrypt traffic. Where RPCSEC is implemented, Kerberos can remain as the authentication mechanism, with TLS replacing the “costly” Generic Security Services (GSS) API's integrity or privacy services. ®