Subject: [http-auth] Sketch or protocol for secure credentials submission & opening up new options for local security

From: Jim McAlear <[email-masked]>
Date: Tue, 4 Dec 2012 18:30:43 -0800 (PST)

Hi All –

Here is the protocol sketch I promised. It turned out to be a little easier and more flexible than I thought.
 
I’ll first cover how the protocol might operate with a conventional browser/user-agent, and then cover how compartmentalization or sandboxing would come into play. In this way we can clearly see where our protocol definition job would be separated from an implementer’s job. It could also lead to benefits to other protocols.
 
I’ll start with a situation where a server wishes the user to perform a critical credentials submission (CCS) – such as for a credit card transaction (but could alternatively cover the submission of a Social Security Number, a Passport number or any number of things that should be protected from identity theft). In this situation, the server would send the client a variant of a HTTP 401 message, which would include as a parameter: a session identifier string. The implication of the variant message would be that the user-agent would need to open up a new HTTPS-like session to the server on a well-defined port – say port 883 for the sake of argument. But the HTTPS-like session would first start with a request-response exchange in the clear; the “request” message would have a header indicating a CCS message, and then a field to indicate the originating service DNS identifier (e.g. buy.merchantx.com) and finally the session identifier string such
 that this session can be associated with the original session at the server end. (Since a proxy may be involved, we can’t rely on an identical client IP address.) The DNS string would be needed if the server runs independent services on it. The “response” message from the server would just be a “continue” message. When the user-agent receives the “continue” message, then a conventional HTTPS session set-up would follow on this port 883. But underneath this session on port 883 would not be general HTML etc., but just a credentials request transaction. This credentials request would be more general than the normal user-id/password combination, to allow the server to specify a number of requested fields – e.g. for a credit card, the server could provide a purchase summary and ask for: a) card number, b) expiry date, c) name as shown on card, and d) card security code (on back of card). Once this exchange would be completed, then the HTTPS
 aspect would close, and a final “complete” message would be sent in the clear from the server to the client. (Additionally, a variant of this could also be defined for the handling of shared-secret/passwords which could employ strong hashing rather than encryption).
 
So this protocol definition doesn’t deviate very much from capabilities already in our larger set; for browser developers the core code needed to implement this might well be completed in a day or so (not including documentation, verification etc.).
 
But now consider how 1) compartmentalization or 2) sandboxing could be applied. 
 
1) Consider a compartmentalized set of circuitry residing on the Network Interface Card of the client that is unreachable from the operating system, whose sole job is to monitor and interact with packets/messages on server port 883.  When this circuitry sees the first outgoing “request” message in the clear, it records the information and kicks into action to divert subsequent 883 messages from going to the operating system, and instead handles the transaction on its own. In parallel with the certificate checking and key exchange, the circuitry could look-up the DNS entry of the server string (e.g. buy.merchantx.com) to confirm consistency with the IP address of the intender server (it could use the client port already on hold for talking to the server on port 883) . It is presumed that the compartmentalized circuitry has something akin to an independent connection to the user keyboard, which also has an embedded display, such that when the
 compartmentalized circuitry prompts the user for action, that all keystrokes are blocked from going to the operating system through a hardware interlock. But there are many possible variants here that protocol designers need not be concerned about. With such a capability, the transaction can be completed without access by neither the operating system nor any resident malware. Thus once the credentials submission is complete, then the “complete” message from the server would be allowed to pass through to the operating system to signify then end of this procedure (so the user-agent/browser would send the initial “request”, and then see a “complete” – and therefore skip all the steps that would normally be triggered by the “continue” message). 

2) Alternatively a sandboxing approach might be attempted. Browser developers have had some success with sandboxing Java and browser operations in general, but the sheer complexity of modern HTML, Javascript, Java, plug-ins and more continually leads to leaks and exploits. But if the developers focused on specifically sandboxing just the highly limited CCS function, they might well achieve a terrific success. And this could be also done at the server as well, where a tightly sandboxed capability to strictly handle credit card (and like) transactions could apply.

So we start to see how a modest variant of our protocol definitions could enable a much greater level of protection of critical credentials. So for a little effort on our part, we get to claim leadership in solving a much larger issue – though others would still have to come through with the harder part of sandboxing or implementing compartmentalized circuitry.  I have no expertise in sandboxing; my embedded experience tells me the compartmentalization approach is viable. In fact, the Zurich Labs of IBM has implemented a comparable compartmentalized approach with their ZTIC device (http://www.zurich.ibm.com/ztic/). The ZTIC approach was presented at a WorldCIS session earlier than my paper and can be considered
as an antecedent to what I covered at WorldCIS this past summer.
 
(Available at:  http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6280198&isnumber=6279697 )
 
Incidentally, this could also lead to benefits to other protocols like POP and SSH and the like. These protocols could also be modified to handle credentials submissions via port 883 in a way that would also permit protection via compartmentalization or sandboxing.
 
I hope this comes across clearly; I’ve tried to cover the main aspects of operation without bogging down in details, but a one-way exposition is never perfect, so let me know if anything isn’t clear. I’m happy to expand on any aspect you wish.
 
Questions/comments/next steps?
 
Jim McAlear
Ottawa, Canada

---

From: Jim McAlear <[email-masked]>
Date: Tue, 11 Dec 2012 17:40:43 -0800 (PST)

Hi All -
 
I hope what I sent out last week was relatively clear - we have a unique opportunity to make some relatively small changes to our protocol suite that will open up valuable new options for local host security to strongly protect users against victimizers.
 
By compartmentalizing credential/authentication transactions within our protocols, it can allow local security efforts to cleanly do the same to support protection of critical credentials that are so often exploited for cyber-crime and identity theft. As described, the changes would require just minor efforts on the part of browser developers and server framework developers and minor efforts in redefining our protocols. And with such changes, compartmentalization or sandboxing could be applied at either, or both, ends of a connection and deliver valuable benefits in part or in whole. And for users, nobody would have to reach for a different device (e.g. mobile phone, smart card etc.) nor be required to enter additional information that he otherwise would have; the solution has the flexibility to allow the user to use the normal keyboard capability of the client device. It can also lead to benefits for applications that utilize other protocols - e.g.
 POP, SSH and more. 
 
A common convention is that silence means consent, so if you have any concerns or issues with this, please let me know. Otherwise I will get started on preparing a draft of the material for insertion into an RFC.
 
I expect that the material will be comprised of: 1) objectives, 2) description of a possible, but not proscibed, hardware reference description that allows compartmentalization of authentication transactions,  3) protocol overview, 4) protocol details for secure credentials submission and 5) protocol details for shared-secret hashing submission. Given that the holiday season has started, with all the: get-togethers, errands, traveling and more, I don't expect to get much done until January. Even then, I'm expecting that I'll put out a draft in sections/stages.
 
So again, if there are any concerns, issues or suggestions, please let me know. Help is also very welcome; this could be an important turning point in protecting users from cyber-criminals - it will be critical to get things right.
 
- Jim McAlear
Ottawa, Canada
 
----- Forwarded Message -----
From: Jim McAlear <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Sent: Tuesday, December 4, 2012 9:30:43 PM
Subject: Sketch or protocol for secure credentials submission & opening up new options for local security

Hi All –

 

 

 
Jim McAlear
Ottawa, Canada