Subject: [http-auth] Proposal for HTTP credentials handling side session

From: Jim McAlear <[email-masked]>
Date: Sat, 26 Jan 2013 16:58:03 -0800 (PST)

Hi All –
Attached is the first outline of the HTTP-Auth submission I
promised last year. There are still quite a few details that need to be pinned
down, but there is enough of a high level specification to shake out any top
level implementation or compatibility concerns. I have provided some quick
outlines for some details sections in order to preview needed refinements. Finally,
at the end I’ve included an open-ended question on how this kind of approach
could add value to other protocols and capabilities within internet systems.
Questions/comments? 
Thanks in advance for looking at this. I’ll be traveling
this coming week with limited access to email; I’ll be able to handle quick
questions, but more complex replies will have to wait until next week.
Jim McAlear
Ottawa, Canada
Title: 
New Security Options for HTTP Authentication Handling of
Credentials and Critical Transactions
Abstract: 
This document defines new options for handling critical
credentials and transactions (that involve the use of passwords, credit card
numbers and more) within the HTTP protocol in order to open up new approaches
to providing host-level security at clients and servers. These new forms of
credentials handling require only minor variations of current HTTP processing
capabilities of current client and server software stacks; what these variants
accomplish, is to layer and structure the protocol details in such a way that
permits different forms of compartmentalization or sandboxing to apply within
hosts such that these critical transactions can be handled outside the reach of
all-to-common host-resident malware. Some compartmentalization examples are
provided herein; these are meant to be suggestive, not prescriptive, and the
structure of the protocol provides implementers with a large degree of
flexibility to configure suitably compartmentalized or sandboxed solutions at
clients and servers.
Introduction: 
The introduction to the draft HTTP 2.0 protocol
specification states: HTTP has been a wildly successful protocol. This is not
only true from an engineering perspective, but also from that of end-users. So
in contemplating improvements to this protocol, it is not only appropriate to
engineer efficiency gains such as SPDY, but to also examine avenues to address
key user concerns. So while HTTP has been wildly successful in connecting users
to all kinds of desired services, the main shortcoming perceived by users is susceptibility to various forms of fraud and
identity theft – especially due to the theft of critical credentials. Of course
this is much more than a worry; such crimes are being committed on a massive,
industrial scale and years of countervailing efforts have not successfully stemmed
this crime wave. The vast majority of these crimes come about due to malware
infections of host computers; it is well beyond the practical ability of
protocol developers to delve into this incredibly complex realm to offer
general solutions against malware exploitation. 
But an opportunity has arisen to define a solution that can
handle critical credentials and transactions outside the reach of (presumed)
host–resident malware.  This proposed
contribution will define optional hardware reference configurations for compartmentalized
handling of key credentials and transactions, and then proceed to define
protocol details that enable such secure handling of this critical information.
For maximum host architecture compartmentalization flexibility, the reference
hardware compartmentalization will focus at the point of the host Network
Interface Card (or Component) – this being the lowest point within the host
architecture operating at the physical layer connection to a network. In this
way, if the protocol can support a compartmentalized credentials handling
interdiction at that low point, then other compartmentalized or sandboxed
options are also opened up at higher layers within the host hardware and
software architectures. So the upshot of this proposed contribution is that it
opens up whole new approaches to host security as far as handling critical
credentials and transactions, though it is up to computer hardware and software
developers to fulfill these within their designs.
Compartmentalization Reference Hardware Configuration: 
The reference hardware configuration defined for this new
specification concerns new functionality of the Network Interface Card (or Component
– either way abbreviated as NIC) of a host computer. It is assumed here that
this component has an additional outboard interface, a USB port for the sake
of concreteness, and new independent functionality to monitor, intercept and
manipulate very specific credentials communications that take place across the
network. This outboard port will be accessible to specific circuitry of the
NIC, but not be exposed in any way to the higher layers of host hardware nor
the operating system. At the client end of the communication, the USB port will
typically attach to a keyboard in a way that the user can enter credentials almost
directly into the transaction protocol without keystrokes going to the host
operating system (and through any malware enabled keystroke-capture capability).
More elaborately, the keyboard would have an embedded display that operates
independently of the operating system, such that the user can view the proposed
transaction/credentials request details and compose a suitable reply if the
request details are satisfactory – just barely off the connection from the
physical layer. This function would be triggered as the result of a
well-defined protocol condition observed in the NIC. When this operation is
triggered, the connected keyboard component will be blocked from sending
keystrokes via the conventional connection to the operating system, until the
credentials transaction has completed or cancelled. At the server end, the USB
port of the NIC would connect to a USB memory/processor stick containing a
database of user passwords or credit card merchant account information, such
that credentials transactions can likewise be completed outside the purview of
the host operating system and thus any resident malware. The next section will
cover the essentials of operation with these configurations – though an example
will also be provided where the compartmentalization doesn’t need to be applied
at the NIC level – thus demonstrating the flexibility for host software and
hardware architects to innovate in the area of compartmentalizing or sandboxing
credentials transactions away from presumed resident malware. And though this
reference configuration makes mention of a physical keyboards, displays and
NICs and outboard ports, these are by no means prescriptive – useful
alternatives to these are exposed within a referenced publication [tbd].
Key Protocol Features for Operation with Reference
Configurations:
Here we begin with a situation where an existing HTTP or
HTTPS connection has already been initiated, and the server software reaches a
condition whereby it needs a credentials submission by a user – be it the
submission of a password, or a set of credit card parameters, or other
sensitive information like a passport number or a Social Security Number. For
the most restrictive case, we will assume here that the existing connection is
HTTPS. At this point we will require the server to send the client a (proposed)
HTTP 308 Message: Request Credentials Side Session. Within the body of this 308
response will be a specification of the intended host (e.g. buy.example.com)
and a one-time transaction identifier (a pseudo-random alphanumeric string) to
associate a to-be-created side session with the original session at the server
end (important for making session associations passing through proxy servers).
At this point the user-agent of at the client will send out a first message to
a well-defined (proposed) server port 446 as if a new HTTPS session were to be
created (this may be done over a new TCP session or a UDP interchange). The
lead message will have the specified host and transaction identifier fields
included in the clear.  The added NIC
based functionality in the client reference configuration would monitor incoming
and outgoing packets to server port 446 and then proceed to intercede and take
over the side session until completion (or cancellation). Thus the client NIC
would then interact with the server to set up a TLS session, using its own
independent encryption capabilities, and once established the server would
provide a specification of an intended transaction and desired user credentials –
such that the compartmentalized functionality of the NIC will then present and
collect these from the user for secure submission to the server. All the while
this is happening, the compartmentalized NIC functionality will block any
packets to and from server port 446 from ever reaching any other components of
the host system. It must be noted that this side session must not involve the
full set of HTTP capabilities, but just a very limited interaction to allow
credentials transactions. The server cannot know if the client NIC incorporates
this functionality, for that matter the client user-agent may not have this
knowledge in advance. Thus if the client NIC does not have this functionality,
or if an enabled NIC notes that a keyboard capability has not been connected to
the outboard port, then these 446 messages are passed to the operating system
and user-agent must complete the transaction per the details of this
specification (in the current fashion that risks malware access). 
A complementary process can occur at the server end. If the
server NIC has the needed compartmentalized functions that are triggered on
port 446 activity, then this capability is triggered to respond to the client
requested side session set-up using its own encryption capabilities and
blocking port 446 messages from reaching the upper hardware and software layers
of the server host. The key exception is that once the compartmentalized NIC
capability has taken over the session, it will send a message up to the higher
layers of the server using port 446 and containing the intended host and
session number (in a different form than what the client side has sent), to
receive from the higher layers of the server the required parameters of the
transaction. For a credit card transaction, these parameters would normally
include the purchase details of: amount to charge and shipping address (if
needed), and then a specification for credit card parameters requested – such
as card number, expiry date and verification code. Such information would be
sent by the higher layers of the server down to port 446 and be intercepted by
the NIC functionality. The NIC would then encapsulate such parameters within
the encrypted session with the client side and await the user response. Upon
receipt of the user credentials from the client end, the NIC and USB key
functionality could then independently contact a credit card clearance service
to validate the transaction. The transaction success/fail response and summary
code would then be passed up to the server on port 446. The details of the
transaction would normally be logged within the attached USB key for an
independent record that is inaccessible by any server-resident malware. In an
alternative interaction, the USB memory stick could contain a database of
password information, and could verify password submissions without malware
having any access to the password database. Other alternatives are described in
a reference publication [tbd].
As discussed earlier, while the protocol definition enables
compartmentalization that can operate just above the physical connection to the
network, other options are still viable. In terms of host security - complexity
is the enemy of security. So consider a high volume online storefront that
might operate at the server: shop.example.com. With today’s sophistication of
shopping sites, involving user reviews and ratings, user-profiling and
just-in-time ad placements, recommender systems, sophisticated searching,
product videos, Facebook tie-ins and so much more, the attack surface presented
to malware operators is substantial. In the past, malware presences on such
sites have harvested immense numbers of credit card credentials to subsequently
perpetrate massive online fraud. So a different compartmentalization approach
at the server end might be to divorce the card handling transaction from the
rest of the shopping site. In such a configuration, the vendor might set-up a
low-complexity site: buy.example.com that will process final check-outs
assembled at shop.example.com. So in this case, upon check-out at
shop.example.com, this server will send out a 308 message specifying a side
session with buy.example.com - to independently handle the credentials
transaction. This dedicated server should ideally have a much smaller attack
surface, since it only needs to handle a small subset of the HTTP protocol,
never mind all the sophisticated features of modern shopping sites, and just
needs to communicate simple transaction parameters with the shopping server –
which should allow for more robust security (all without extra NIC
functionality). Such a side channel set-up might also be configured in some way
at the client end (using Bluetooth or near-field communications) with an
independent device such as a mobile phone – if such a device can be trusted to
be malware-free (a big “if”).
Additional Modes of Provided Protection:
The above description has described configurations that work
well to keep critical credentials outside the purview of resident host malware
– but this isn’t the only type of fraud that such configurations can protect
against. Consider a malware presence on the client device that actually alters the user-agent/browser software in such a way as to perform
man-in-the-middle tampering with transactions in a way that is hidden from the
user. In this scenario, a user might think he is making a modest purchase for
delivery to his house, or be making a certain transaction while banking online,
but behind the scenes, the malware is making completely different transactions
to the malware operator’s advantage – such as making a large purchase with
delivery specified to a malware operator’s designated address. With the
specification above, whatever the server sees as the issued transaction coming
out of the client (possibly fraudulent), is actually reflected back to the user
in the side session and is intercepted by the compartmentalized function for
raw presentation to the user (e.g. “Purchase $8192.64 for delivery to Badtown,
Fraudistan”), such that the user can truly verify that what he intended has
gone through unaltered by malware. This can also apply to stock purchases,
financial transfers and the like during online banking sessions.
…More to come…
Of course many more details need to be handled. Here are
outlines of some of them.
Side session encryption: The transactions are very short –
we might just restrict things to UDP and only allow the public key encryption
and not allow change to options such as RC4 to minimize compartmentalized
functionality. On the other hand, encryption like RC4 isn’t very complex; and
should we want to evolve things to allow the user to submit more complex
information securely, such as health information contained on a USB key, then
an RC4 capability would be useful.
Small side session brute force encryption cracking: Small
encryption payloads are subject to brute force attacks in general, substantial “nonce”
inclusions will be required. It will also be helpful to reduce guessable
plaintext entropy that facilitates cryptographic attacks. So rather than a
server sending out requested credentials parameters as full text, such as
“enter card number”, “enter expiration date” and the so on, we could predefine many
common fields, and just require the server to list index numbers of these
predefined fields to be presented to the user in a native language form at the
client end. Candidate common fields would be: 1) user ID, 2) password, 3)
account ID, 4) transaction verification code, 5) card holder name, 6) card
number, 7) expiration date, 8) card verification code, 9) address line 1, etc.
Compartmentalized NIC capability: The compartmentalized NIC function
would need to use/verify DNS look-up info for the side session channel and
present it to the user. The user would need to be sure that malware tampering
with the browser operation isn’t sending him to a false-front web site.
Certificate checking and warnings also apply here.
Password submission: In some circumstances, it might be
advantageous to allow hashed passwords to be submitted by the side channel
without the complexity of a higher layer of encryption.
… and more …
======================
Finally – At some point I’d like to have a broader
discussion on the role for pairing up well-defined ports and protocols with dedicated/embedded
hardware packet/message handling that cannot be mediated by higher layers of software.
Before I came involved with internet systems in the late 1990’s, my job was
largely focused on traditional circuit-switched telecom networks. While these
networks did not have anything near the flexibility and power of packet-switched
internets, the relatively locked down signalling and routing functions didn’t
enable the widespread misuse that has been seen within internets. So I’m wondering
if there should not be well-defined protocol ports that trigger embedded
hardware handling of functions that are free from intervention of higher layer (possibly
malicious) software that may be running on a given router/proxy/gateway. For a
specific example, consider a home-gateway – some of which have be infected by
malware – and thus can be reprogrammed by a malware operator. If some functions
of such a gateway were immutable to higher level control, then even in a
presence of malware, some critical functions could still correctly operate for
connected PCs. Consider DNS for example. Suppose a lower layer hardware
capability existed that independently makes a log of a boot protocol connection
to a DSL or cable modem network, noting the IP addresses of top level DNS domains.
Then imagine that when a PC connects to this gateway, that the same hardware
component supplies these DNS IP addresses to the PCs through a subsequent boot
protocol transaction. This means that malware on the gateway would not be able
to tamper with this critical information. Now further suppose that this
hardware capability were responsible for the passing of DNS/port 53
communications between each side of the gateway. Again, the happy result would
be that malware on the gateway would be unable to tamper with these critical
sessions.
Were we to contemplate such configurations for DNS,
certificate authorities and more, we might well achieve the best of traditional
telecom and internet worlds, with broad application flexibility coupled to a
tamper-proof core infrastructure.
Comments/questions?