From jim.mcalear@rogers.com Sun Dec 2 14:32:05 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A152A21F88EA for ; Sun, 2 Dec 2012 14:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaKAGUwkTWAM for ; Sun, 2 Dec 2012 14:32:04 -0800 (PST) Received: from nm25.bullet.mail.ne1.yahoo.com (nm25.bullet.mail.ne1.yahoo.com [98.138.90.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4601C21F88E9 for ; Sun, 2 Dec 2012 14:32:04 -0800 (PST) Received: from [98.138.226.179] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 02 Dec 2012 22:31:59 -0000 Received: from [98.138.89.192] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 02 Dec 2012 22:31:57 -0000 Received: from [127.0.0.1] by omp1050.mail.ne1.yahoo.com with NNFMP; 02 Dec 2012 22:31:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 324949.5875.bm@omp1050.mail.ne1.yahoo.com Received: (qmail 66125 invoked by uid 60001); 2 Dec 2012 22:31:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1354487517; bh=1M7quZ/At81MAy71Tb5FKoJUZBf5nbYqbzAHi31/Uus=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j7VLdyNq/jH36WtZ5kKGFpSa8f0NHDwhdANmo2lcTPrBYJi3J9bnn5fkDTLc1iUF3HI6buUuJJNLmCzk3ueMSGjeCwfhGXBdjA6EhDQ7OEtoRVga4QldxaA/2omDBvhHphMudmoHTWO93/kP2hwu1UnYqc2zNfyzA8dagIbTB1Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QPhAEL0yRHhGxcfgc8u8W9Muhyxhk9n39H/tf1Oro+G2VMPCW+Dt+zg9BzlSSFuU9hjVqEXzwdXif4J3lGCxjz4iXNkYaDu4Oz60T+Fy/sAq9ra801uN7yAObV8JQSKyEVzLNBoEXE46HFZ0aGd65W7lKRAtnHOQBalb/kIEY2A=; X-YMail-OSG: qT7Ola0VM1lwtW.14EnYqaMEnq8DDrcffydrTtNNxIM_wUt 2scRsQLTaolPuTB4GDnpPpw2iP97P5luoBr1OeDNu3ZvwinUWUidXcjs.sob jQSo_RpoOvC365lx2GKOkv1RKmC0E1Q6gy4kP1Oq8aq5WscW5HX4T9YcdLty dbEfKJW47nzLKo.uuaH_uxrZCudc.zoxZql1tQMs3KvbdibcaMBmgaWXdSp6 t_fPweC6gJCNjuhReUW1m3fad0BhmHBDmrPz8mxOVgu71RbAox9PnX9C.I6U wew7Bp1rg7w.OVkYxZYytgNuQNPjUDeuuU0sRNIxvTZY9uYQ7LTLREoxEdMN 8r91_F0.kt_fIIWOR1BdzR9ShvDAOON34C9WAL2_Q5NXsm6acsOfX7PxXDij A3AJvRJfdTJVpS9tYeHHPeMIPyDueTGiobFG6xrXzg9o_LZhWTx4ma8whI59 xjwIZ2QtfBhKmnhQ4ulS8P1dS4CCj4q1Uc6sAgaZ0rZ8hrk1hZXi.Ups7ZXe C3PZKHxUDYw-- Received: from [99.245.236.70] by web122103.mail.ne1.yahoo.com via HTTP; Sun, 02 Dec 2012 14:31:56 PST X-Rocket-MIMEInfo: 001.001, SGkgTmljbyAtCsKgClRoYW5rcyBmb3IgdGhpcy4gSSd2ZSBsb25nIHdvcmtlZCBpbiB0aGUgc2Vuc2libGUgYXJlYSBvZiBwcm90b2NvbHMsIGFuZCBpdCdzIGp1c3QgaW4gdGhlIHBhc3QgZmV3IHllYXJzIHRoYXQgSSd2ZSBiZWVuIGV4cG9zZWQgdG8gdGhlIGN5YmVyLXNlY3VyaXR5IGFyZW5hIC0gYW5kIEkgaGF2ZSB0byBhZG1pdCB0aGF0IEknbSBnZW5lcmFsbHkgaG9ycmlmaWVkIGJ5IHRoZSBzaGVlciBtb3Jhc3Mgb2YgY29tcGxleGl0eSBpbnZvbHZlZCB0aGVyZS4gU28gb2YgY291cnNlLCB0byBwcm8BMAEBAQE- X-RocketYMMF: jim.mcalear@rogers.com X-Mailer: YahooMailWebService/0.8.128.478 References: <1354151007.57636.YahooMailNeo@web122104.mail.ne1.yahoo.com> Message-ID: <1354487516.59177.YahooMailNeo@web122103.mail.ne1.yahoo.com> Date: Sun, 2 Dec 2012 14:31:56 -0800 (PST) From: Jim McAlear To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1287737115-353454212-1354487516=:59177" Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jim McAlear List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 22:32:05 -0000 --1287737115-353454212-1354487516=:59177 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nico -=0A=C2=A0=0AThanks for this. I've long worked in the sensible area= of protocols, and it's just in the past few years that I've been exposed t= o the cyber-security arena - and I have to admit that I'm generally horrifi= ed by the sheer morass of complexity involved there. So of course, to proce= ed pragmatically, protocol designers need to assume local security - even t= hough this isn't a good assumption in reality - because without such an ass= umption, protocol designers wouldn't be able to get on with the job. But in= the fight between attackers and defenders, cyber security experts are nowh= ere near acheiving the level of success that protocol designers have; so un= less they start to contemplate some revolutionary new approaches, then the = trends of massive, industrial scale victimization will continue for a long = time.=C2=A0Now since protocols designers are so far ahead in acheiving thei= r objectives, perhaps it is time for local security experts to learn a thin= g or two from us. =0A=C2=A0=0AWhat I would like to submit is a=C2=A0first s= ketch of an authentication=C2=A0protocol, that could be implemented in a un= it of compartmentalized circuitry that runs independent of the host's opera= ting system, that will ensure that an authentication transaction can be com= pleted securely.=C2=A0The authentication procedure would=C2=A0be designed i= n such a way, that it would be seamlessly operable by user-agents/browsers,= regardless of=C2=A0whether the local hardware supports a compartmentalized= authentication capablity or not. Furthermore, it will not require any more= fundamental capability than that which is already contained within modern = browsers (certificate checking, key-exchange, encryption etc.). But if the = hardware were to have a secure compartment, then this small unit could impl= ement the authentication procedure on its own (perhaps as a state machine, = perhaps as an embedded capability) - in a way that thwarts any malware acce= ss or tampering with the authentication. With such a secure compartmentalized transaction capability, we could reli= ably keep key credentials (passwords, credit card numbers and more) out of = the reach of malware, and thwart all the easy-money silient victimization t= hat happens as well as wider identity theft crimes.=0A=C2=A0=0AWith such a = flexibility built in, we could well see military, government and financial = sectors begin to adopt the compartmentalization approach within their opera= tions, and then a mass-market roll-out could quickly follow. It's clear tha= t the local security people need help and require novel new approaches to a= cheive our shared objectives. Would it hurt for=C2=A0me to submit a quick s= ketch of how the protocol would operate? I'll prepare a sketch over the nex= t few days - it will apply to the user-agent/browser side first; I'll cover= the server end shortly thereafter. Protocol designers have already done a = lot to prevent victimization of users - would it hurt to consider one furth= er step forward that could solidify the acheivement in a way that fills the= gaping hole that local security experts have left open?=0A=C2=A0=0AQuestio= ns/comments/next steps?=0A=C2=A0=0A- Jim McAlear=0AOttawa, Canada=0A=C2=A0= =0A =0A=0A________________________________=0A From: Nico Williams =0ATo: Jim McAlear =0ACc: "http-auth@i= etf.org" =0ASent: Friday, November 30, 2012 5:12:21 PM= =0ASubject: Re: [http-auth] Reboot: Protecting users and institutions from = victimization by eavesdroppers & cyber criminals=0A =0AOn Wed, Nov 28, 201= 2 at 7:03 PM, Jim McAlear wrote:=0A> Time after time= , through efforts like: SSH, HTTPS and IPSEC and much more, the IETF has tr= ied to protect users and institutions from victimization by network eavesdr= oppers and man-in-the-middle operators. But cybercriminals easily defeat ou= r goals by implanting malware on servers and PCs =E2=80=93 resulting in vic= timization on a massive, industrial scale. The aim of this contribution is = to show that a solution to our longstanding goal is potentially within reac= h =E2=80=93 and that if we carefully craft a new authentication procedure t= hat is flexible enough to handle some novel hardware configurations, then w= e can finally provide users and institutions with our long-desired protecti= on against victimization by cyber criminals =E2=80=93 at least in the impor= tant areas of protecting critical credentials and transactions (safe e-comm= erce). The attachment outlines the solution at a high level.=0A>=0A> Do you= agree that this is a laudable goal? Questions/comments/next steps?=0A=0ALo= cal security is something that our protocols all assume: they extend=0Aloca= l security to the network, not the other way around.=C2=A0 This is true=0Ao= f *all* of our security protocols: IPsec, SSHv2, TLS, Kerberos, SASL,=0A...= =C2=A0 We work on protocols here, not so much local security, but we do=0At= ry to make our protocols easier to protect from local compromises.=0AFor ex= ample, Kerberos has temporary credentials the compromise of=0Awhich is easi= er to recover from than the compromise of long-term=0Acredentials; PKIX is = amenable to smartcard and other token solutions.=0AThis is all very nice, b= ut sadly, that's about as far as we can go=0Awith network protocols, maybe = we can go as far as NEA (an attempt to=0Aauthenticate end-point state), com= bined with TPMs and OSes that are=0Aamenable to secure bootstrapping with T= PMs.=0A=0AI'd like to separate what features we want in protocols to improv= e=0Asecurity in the face of local compromises (namely, we want temporary=0A= credentials and/or suitability for smartcards) from what we want done=0Afor= local security.=C2=A0 The two are very different fields of work that=0Abar= ely intersect, and mostly only because we must assume that local=0Asecurity= will be compromised from time to time.=0A=0A(Yes, I know, I mostly only de= alt with client-side local security above.)=0A=0ANico=0A-- --1287737115-353454212-1354487516=:59177 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Nico -
 
Thanks for this. I've long worked in the se= nsible area of protocols, and it's just in the past few years that I've bee= n exposed to the cyber-security arena - and I have to admit that I'm genera= lly horrified by the sheer morass of complexity involved there. So of cours= e, to proceed pragmatically, protocol designers need to assume local securi= ty - even though this isn't a good assumption in reality - because without = such an assumption, protocol designers wouldn't be able to get on with the job. But in the fight between attackers and defenders, cyber security expe= rts are nowhere near acheiving the level of success that protocol designers= have; so unless they start to contemplate some revolutionary new approache= s, then the trends of massive, industrial scale victimization will continue= for a long time. Now since protocols designers are so far ahead in ac= heiving their objectives, perhaps it is time for local security experts to = learn a thing or two from us.
 
W= hat I would like to submit is a first sketch of an authentication = ;protocol, that could be implemented in a unit of compartmentalized circuitry that runs independent of the host's operating system, that will = ensure that an authentication transaction can be completed securely. T= he authentication procedure would be designed in such a way, that it w= ould be seamlessly operable by user-agents/browsers, regardless of whe= ther the local hardware supports a compartmentalized authentication capabli= ty or not. Furthermore, it will not require any more fundamental capability= than that which is already contained within modern browsers (certificate c= hecking, key-exchange, encryption etc.). But if the hardware were to have a= secure compartment, then this small unit could implement the authenticatio= n procedure on its own (perhaps as a state machine, perhaps as an embedded = capability) - in a way that thwarts any malware access or tampering with th= e authentication. With such a secure compartmentalized transac= tion capability, we could reliably keep key credentials (passwords, credit card numbers and more) out of the reach of malware, and thwart all = the easy-money silient victimization that happens as well as wider identity= theft crimes.
 
With such a flexi= bility built in, we could well see military, government and financial secto= rs begin to adopt the compartmentalization approach within their operations= , and then a mass-market roll-out could quickly follow. It's clear that the= local security people need help and require novel new approaches to acheiv= e our shared objectives. Would it hurt for me to submit a quick sketch= of how the protocol would operate? I'll prepare a sketch over the next few days - it will apply to the user-agent/browser side first; I'll cover = the server end shortly thereafter. Protocol designers have already done a l= ot to prevent victimization of users - would it hurt to consider one furthe= r step forward that could solidify the acheivement in a way that fills the = gaping hole that local security experts have left open?
<= /span> 
Questions/comments/next steps?
 
- Jim McAlear
Ottawa, Canada
 

From: Nico Wil= liams <nico@cryptonector.com>
To= : Jim McAlear <jim.mcalear@ieee.org>
Cc: "http-auth@ietf.org" <http-auth@ietf= .org>
Sent: Friday= , November 30, 2012 5:12:21 PM
Su= bject: Re: [http-auth] Reboot: Protecting users and institutions= from victimization by eavesdroppers & cyber criminals
On Wed, Nov 28, 2012 at 7:03 PM, Jim McAlear <jim.mcalear@ie= ee.org> wrote:
> Time after time, through efforts like: SSH, H= TTPS and IPSEC and much more, the IETF has tried to protect users and insti= tutions from victimization by network eavesdroppers and man-in-the-middle o= perators. But cybercriminals easily defeat our goals by implanting malware = on servers and PCs =E2=80=93 resulting in victimization on a massive, industr= ial scale. The aim of this contribution is to show that a solution to our l= ongstanding goal is potentially within reach =E2=80=93 and that if we caref= ully craft a new authentication procedure that is flexible enough to handle= some novel hardware configurations, then we can finally provide users and = institutions with our long-desired protection against victimization by cybe= r criminals =E2=80=93 at least in the important areas of protecting critica= l credentials and transactions (safe e-commerce). The attachment outlines t= he solution at a high level.
>
> Do you agree that this is a la= udable goal? Questions/comments/next steps?

Local security is someth= ing that our protocols all assume: they extend
local security to the net= work, not the other way around.  This is true
of *all* of our secur= ity protocols: IPsec, SSHv2, TLS, Kerberos, SASL,
...  We work on p= rotocols here, not so much local security, but we do
try to make our protocols e= asier to protect from local compromises.
For example, Kerberos has tempo= rary credentials the compromise of
which is easier to recover from than = the compromise of long-term
credentials; PKIX is amenable to smartcard a= nd other token solutions.
This is all very nice, but sadly, that's about= as far as we can go
with network protocols, maybe we can go as far as N= EA (an attempt to
authenticate end-point state), combined with TPMs and = OSes that are
amenable to secure bootstrapping with TPMs.

I'd lik= e to separate what features we want in protocols to improve
security in = the face of local compromises (namely, we want temporary
credentials and= /or suitability for smartcards) from what we want done
for local securit= y.  The two are very different fields of work that
barely intersect= , and mostly only because we must assume that local
security will be compromised from time to time.

(Yes, I know, I mostly only dealt= with client-side local security above.)

Nico
--


--1287737115-353454212-1354487516=:59177-- From yaronf.ietf@gmail.com Sun Dec 2 21:20:50 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A811C21F8710 for ; Sun, 2 Dec 2012 21:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDntRAUl8+im for ; Sun, 2 Dec 2012 21:20:49 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6858821F870E for ; Sun, 2 Dec 2012 21:20:49 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1103361eaa.31 for ; Sun, 02 Dec 2012 21:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pOPGnxw8iYN5mYpmFtgrotW3lHXQyy2MAfMtz4KRUKw=; b=vkovIF7zqJdSHSucVZf38DtdrO7AzPpq3IHwpclzESaFj0CyJnKapNR8q/pzV4qrRi XjUC4iL+CQ4+Ws4no1geQ4VQhz8Nd+pXcm5cHtXK+x1erZFcNzJ7WHLGlmt3IfTR4aoG aOJFjyvgz4FkpljYZvZsI6SNp8k6XrVfzlztQtoGWo1BaF5F7fAh2oFCn/o8Uds+F0qU sQLJdTolV+7VQfTtGcw+et+YqYuUwNi2GgscNPUOQYNPGqAFtV0Y+v+/8Pb7Z6D/ULhJ mhSnpNFBAKBIcJIIGcLECVLT4UB4GM+ljsK1F31ptt3l7HdY8vrtQwM/wtwBPEZrxWo4 nd4w== Received: by 10.14.177.1 with SMTP id c1mr32242328eem.8.1354512048592; Sun, 02 Dec 2012 21:20:48 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-164-29.red.bezeqint.net. [79.183.164.29]) by mx.google.com with ESMTPS id b49sm12795856eem.16.2012.12.02.21.20.45 (version=SSLv3 cipher=OTHER); Sun, 02 Dec 2012 21:20:47 -0800 (PST) Message-ID: <50BC36AB.6080506@gmail.com> Date: Mon, 03 Dec 2012 07:20:43 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jim McAlear References: <1354151007.57636.YahooMailNeo@web122104.mail.ne1.yahoo.com> <1354487516.59177.YahooMailNeo@web122103.mail.ne1.yahoo.com> In-Reply-To: <1354487516.59177.YahooMailNeo@web122103.mail.ne1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 05:20:50 -0000 Hi Jim, to be more widely applicable, I would suggest that your proposal should cover TPM assertions, in addition to the more exotic compartmentalization that you suggest in your slide deck. TPM after all is widely available, and is (very slowly) gaining some software support. I realize that TPM can only authenticate the machine, while your proposal can also authenticate the user. Thanks, Yaron On 12/03/2012 12:31 AM, Jim McAlear wrote: > Hi Nico - > Thanks for this. I've long worked in the sensible area of protocols, and > it's just in the past few years that I've been exposed to the > cyber-security arena - and I have to admit that I'm generally horrified > by the sheer morass of complexity involved there. So of course, to > proceed pragmatically, protocol designers need to assume local security > - even though this isn't a good assumption in reality - because without > such an assumption, protocol designers wouldn't be able to get on with > the job. But in the fight between attackers and defenders, cyber > security experts are nowhere near acheiving the level of success that > protocol designers have; so unless they start to contemplate some > revolutionary new approaches, then the trends of massive, industrial > scale victimization will continue for a long time. Now since protocols > designers are so far ahead in acheiving their objectives, perhaps it is > time for local security experts to learn a thing or two from us. > What I would like to submit is a first sketch of an > authentication protocol, that could be implemented in a unit of > compartmentalized circuitry that runs independent of the host's > operating system, that will ensure that an authentication transaction > can be completed securely. The authentication procedure would be > designed in such a way, that it would be seamlessly operable by > user-agents/browsers, regardless of whether the local hardware supports > a compartmentalized authentication capablity or not. Furthermore, it > will not require any more fundamental capability than that which is > already contained within modern browsers (certificate checking, > key-exchange, encryption etc.). But if the hardware were to have a > secure compartment, then this small unit could implement the > authentication procedure on its own (perhaps as a state machine, perhaps > as an embedded capability) - in a way that thwarts any malware access or > tampering with the authentication. With such a secure compartmentalized > transaction capability, we could reliably keep key credentials > (passwords, credit card numbers and more) out of the reach of malware, > and thwart all the easy-money silient victimization that happens as well > as wider identity theft crimes. > With such a flexibility built in, we could well see military, government > and financial sectors begin to adopt the compartmentalization approach > within their operations, and then a mass-market roll-out could quickly > follow. It's clear that the local security people need help and require > novel new approaches to acheive our shared objectives. Would it hurt > for me to submit a quick sketch of how the protocol would operate? I'll > prepare a sketch over the next few days - it will apply to the > user-agent/browser side first; I'll cover the server end shortly > thereafter. Protocol designers have already done a lot to prevent > victimization of users - would it hurt to consider one further step > forward that could solidify the acheivement in a way that fills the > gaping hole that local security experts have left open? > Questions/comments/next steps? > - Jim McAlear > Ottawa, Canada > > *From:* Nico Williams > *To:* Jim McAlear > *Cc:* "http-auth@ietf.org" > *Sent:* Friday, November 30, 2012 5:12:21 PM > *Subject:* Re: [http-auth] Reboot: Protecting users and institutions > from victimization by eavesdroppers & cyber criminals > > On Wed, Nov 28, 2012 at 7:03 PM, Jim McAlear > wrote: > > Time after time, through efforts like: SSH, HTTPS and IPSEC and much > more, the IETF has tried to protect users and institutions from > victimization by network eavesdroppers and man-in-the-middle operators. > But cybercriminals easily defeat our goals by implanting malware on > servers and PCs – resulting in victimization on a massive, industrial > scale. The aim of this contribution is to show that a solution to our > longstanding goal is potentially within reach – and that if we carefully > craft a new authentication procedure that is flexible enough to handle > some novel hardware configurations, then we can finally provide users > and institutions with our long-desired protection against victimization > by cyber criminals – at least in the important areas of protecting > critical credentials and transactions (safe e-commerce). The attachment > outlines the solution at a high level. > > > > Do you agree that this is a laudable goal? Questions/comments/next steps? > > Local security is something that our protocols all assume: they extend > local security to the network, not the other way around. This is true > of *all* of our security protocols: IPsec, SSHv2, TLS, Kerberos, SASL, > ... We work on protocols here, not so much local security, but we do > try to make our protocols easier to protect from local compromises. > For example, Kerberos has temporary credentials the compromise of > which is easier to recover from than the compromise of long-term > credentials; PKIX is amenable to smartcard and other token solutions. > This is all very nice, but sadly, that's about as far as we can go > with network protocols, maybe we can go as far as NEA (an attempt to > authenticate end-point state), combined with TPMs and OSes that are > amenable to secure bootstrapping with TPMs. > > I'd like to separate what features we want in protocols to improve > security in the face of local compromises (namely, we want temporary > credentials and/or suitability for smartcards) from what we want done > for local security. The two are very different fields of work that > barely intersect, and mostly only because we must assume that local > security will be compromised from time to time. > > (Yes, I know, I mostly only dealt with client-side local security above.) > > Nico > -- > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nico@cryptonector.com Mon Dec 3 09:35:20 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50121F885B for ; Mon, 3 Dec 2012 09:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRt4wHGT+6VY for ; Mon, 3 Dec 2012 09:35:19 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9491F21F8715 for ; Mon, 3 Dec 2012 09:35:19 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 47CCA20204B for ; Mon, 3 Dec 2012 09:35:19 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 22B64202022 for ; Mon, 3 Dec 2012 09:35:19 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2528049iaz.31 for ; Mon, 03 Dec 2012 09:35:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.53.193 with SMTP id d1mr7119435igp.69.1354556118633; Mon, 03 Dec 2012 09:35:18 -0800 (PST) Received: by 10.64.12.69 with HTTP; Mon, 3 Dec 2012 09:35:18 -0800 (PST) In-Reply-To: <1354487516.59177.YahooMailNeo@web122103.mail.ne1.yahoo.com> References: <1354151007.57636.YahooMailNeo@web122104.mail.ne1.yahoo.com> <1354487516.59177.YahooMailNeo@web122103.mail.ne1.yahoo.com> Date: Mon, 3 Dec 2012 11:35:18 -0600 Message-ID: From: Nico Williams To: Jim McAlear Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Reboot: Protecting users and institutions from victimization by eavesdroppers & cyber criminals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:35:20 -0000 On Sun, Dec 2, 2012 at 4:31 PM, Jim McAlear wrote: > What I would like to submit is a first sketch of an authentication protocol, > that could be implemented in a unit of compartmentalized circuitry that runs > independent of the host's operating system, that will ensure that an > authentication transaction can be completed securely. The authentication > [...] In other words, you want an HSM/smartcard ("compartmentalized circuitry that runs independent of the host's OS") on the client side. > Questions/comments/next steps? We all want an HSM on the client side. With smartphones we're at least getting to where users carry devices with them; before the password was king. But even now password are still the fallback plan and will continue to be for the foreseeable future. And as for HSMs, we're still not close to where we can require them, or even count on more than a tiny proportion of the population having them. I wish it were not so. But there's a few problems: - users don't always have such devices with them (indeed, they almost never do, though this could change if they were built into smartphones and tablets) - local security still matters: the user still interacts with the HSM through the local OS, and it has to be so; if local security is compromised, then the attacker can still use the HSM - PIN entry doesn't help enough: if it happens too often the user will be very annoyed and the technology might fail, but if it doesn't happen often enough then attackers can use the HSM without the user's knowledge (at least there's auditing...) - PIN entry really also needs to be accompanied by a display of what credentials will be used and what for -- without this the user is left only to correlate the timing of a PIN entry requirement with the timing of user actions - PIN entry through the host is susceptible to theft - PIN entry external to the host requires a PIN entry pad, something that is not going to happen in smartphones nor tablets; see above comment about PIN entry UI - the HSM has to be in smartphones/tablets -- users don't want to carry N > 1 (or maybe 2) devices - device loss (theft, loss, accidental destruction) must be covered, but in that case the only thing that works is authenticating the user without the help of any devices, which kinda means: passwords and/or little pieces of paper claiming to have been issued by some government I'm not trying to be a downer here. Local security will always matter. We have to do better in the realm of local security, much, much better. There's no avoiding it. In the meantime we have other pressing problems that canbe addressed more easily/quickly. Quick question: do we have statistics on MITB attacks? Nico -- From jim.mcalear@rogers.com Tue Dec 4 18:30:50 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E3021F8BCD for ; Tue, 4 Dec 2012 18:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIEky0nu+2XJ for ; Tue, 4 Dec 2012 18:30:48 -0800 (PST) Received: from nm49-vm1.bullet.mail.ne1.yahoo.com (nm49-vm1.bullet.mail.ne1.yahoo.com [98.138.121.129]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2B821F8BB4 for ; Tue, 4 Dec 2012 18:30:47 -0800 (PST) Received: from [98.138.90.49] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 05 Dec 2012 02:30:43 -0000 Received: from [98.138.87.4] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 05 Dec 2012 02:30:43 -0000 Received: from [127.0.0.1] by omp1004.mail.ne1.yahoo.com with NNFMP; 05 Dec 2012 02:30:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 260090.38077.bm@omp1004.mail.ne1.yahoo.com Received: (qmail 78046 invoked by uid 60001); 5 Dec 2012 02:30:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1354674643; bh=eekj0kZwWBzbBlJ8kjh1gWKKmLOpvkxqlj6zqfjkKaM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=g4+bKzFEB7l7O9i4LdAOEXe8Je0m4NcJGjrl6rdhimu3RU7ZXhnouA5OoO4xRFCwVagNxAZ2ZFscqB+2VYYgVbE3+M1Pz8fM7dzN4m0CaUPxqcSZRrvwYCuim1MsGYBIX4rM0bVUGoVfNA4PXX/Hpj/p+d6f+QEeLMb00YIyR8o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=jx7MOy4927CWyLTqCFVr4rw+c16z17jYLgPXaDA2L9DX09fJAe9nhqQK2P4qk3PvY5B8SBhEGTJUmNE0kWB0cFGBra2nhIWeujwbWpVcUMA1DR4PK8+goUqrqd4FUoSyMvRmvS/8taZ0H1O23weK/HPiJpAu4QXb+FQIC2mDbik=; X-YMail-OSG: 7fvOj84VM1lYEhPKm9izue__mZO0IV_6_YH72Rlx5nH3hoK 8R8.8vHz5BElMHV857mSze.6c2FFxzUriww9ckSfxFcZzeKCIsLBHCnOi4XD E27juSaYkETkfo_aSJhMo2mnIB0CdO9EgVQDT8BB.90yf8gUFcLizH2FZNAg RJ4.zkssN6em5leAERQ8JI16a73H3RlB69neEY.VIy3042UnvxPkWqxlp1Yc Vr21KEhVbfMOGrAR9mD4FtzhE_wXMhj.Kppa04d4sKZg_8FHJF6mh90MKFip M5eAlHYrDxNOL0.JQDiZEyY8X5sBdMM2IJ6f.NN5IGY8_wEyp.DxJ3k_fmp_ lCJBW2j2hQ.oZK0cDJlR5G2xj7hZ_EyQe5I9IDHeyS_IxhWbvksadfidnK4N tK4TcrykKCFhgDwqiNPr2lRjENZZubrh1L5dxMuzwODiGCCT5QqIcPyNZTL3 mBRcDz8cOb5ofKfRjuNMDUYjlEgq.DQ51BVfbih4HcZ9gl9iUKs6YsjG14QA w6CTQkNfE7I6sLSNeKirdWDRw0H5uPeLqr89jsYdi1A2uvXCsp2J9GCiz7Aa 2jktlPVuvUuxl.Fi4gHTzBxBDlAORZfOEvzzHa4XYAok0uteOF7uokgpVuXD kTlN_zAUaWr2LRJ7_bHlaiURgXOS99Rt.VBfCaKgbmrwf9hktEB5c5x8blRO TXyQ3Mg1rFqlp87Bkt4KwVVMQg_Rh8V8NMt4O5ti54kQsqYSS1cI- Received: from [99.245.236.70] by web122104.mail.ne1.yahoo.com via HTTP; Tue, 04 Dec 2012 18:30:43 PST X-Rocket-MIMEInfo: 001.001, SGkgQWxsIOKAkwoKSGVyZSBpcyB0aGUgcHJvdG9jb2wgc2tldGNoIEkgcHJvbWlzZWQuIEl0IHR1cm5lZCBvdXQgdG8gYmUgYSBsaXR0bGUgZWFzaWVyIGFuZCBtb3JlIGZsZXhpYmxlIHRoYW4gSSB0aG91Z2h0LgrCoApJ4oCZbGwgZmlyc3QgY292ZXIgaG93IHRoZSBwcm90b2NvbCBtaWdodCBvcGVyYXRlIHdpdGggYSBjb252ZW50aW9uYWwgYnJvd3Nlci91c2VyLWFnZW50LCBhbmQgdGhlbiBjb3ZlciBob3cgY29tcGFydG1lbnRhbGl6YXRpb24gb3Igc2FuZGJveGluZyB3b3VsZCBjb21lIGludG8gcGxheS4BMAEBAQE- X-RocketYMMF: jim.mcalear@rogers.com X-Mailer: YahooMailWebService/0.8.128.478 Message-ID: <1354674643.64480.YahooMailNeo@web122104.mail.ne1.yahoo.com> Date: Tue, 4 Dec 2012 18:30:43 -0800 (PST) From: Jim McAlear To: "http-auth@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-851882195-27720059-1354674643=:64480" Subject: [http-auth] Sketch or protocol for secure credentials submission & opening up new options for local security X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jim McAlear List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 02:30:50 -0000 ---851882195-27720059-1354674643=:64480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All =E2=80=93=0A=0AHere is the protocol sketch I promised. It turned out= to be a little easier and more flexible than I thought.=0A=C2=A0=0AI=E2=80= =99ll first cover how the protocol might operate with a conventional browse= r/user-agent, and then cover how compartmentalization or sandboxing would c= ome into play. In this way we can clearly see where our protocol definition= job would be separated from an implementer=E2=80=99s job. It could also le= ad to benefits to other protocols.=0A=C2=A0=0AI=E2=80=99ll start with a sit= uation where a server wishes the user to perform a critical credentials sub= mission (CCS) =E2=80=93 such as for a credit card transaction (but could al= ternatively cover the submission of a Social Security Number, a Passport nu= mber 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 40= 1 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 po= rt =E2=80=93 say port 883 for the sake of argument. But the HTTPS-like sess= ion would first start with a request-response exchange in the clear; the = =E2=80=9Crequest=E2=80=9D message would have a header indicating a CCS mess= age, 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 serve= r end. (Since a proxy may be involved, we can=E2=80=99t rely on an identica= l client IP address.) The DNS string would be needed if the server runs ind= ependent services on it. The =E2=80=9Cresponse=E2=80=9D message from the se= rver would just be a =E2=80=9Ccontinue=E2=80=9D message. When the user-agen= t receives the =E2=80=9Ccontinue=E2=80=9D message, then a conventional HTTP= S 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 norma= l user-id/password combination, to allow the server to specify a number of = requested fields =E2=80=93 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 exch= ange would be completed, then the HTTPS aspect would close, and a final =E2=80=9Ccomplete=E2=80=9D message would b= e 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).=0A=C2=A0=0ASo th= is protocol definition doesn=E2=80=99t deviate very much from capabilities = already in our larger=C2=A0set; for browser developers the core code needed= to implement this=C2=A0might well be completed in a day or so=C2=A0(not in= cluding documentation, verification etc.).=0A=C2=A0=0ABut now consider how = 1) compartmentalization or 2) sandboxing could be applied. =0A=C2=A0=0A1) C= onsider a compartmentalized set of circuitry residing on the Network Interf= ace 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 8= 83. =C2=A0When this circuitry sees the first outgoing =E2=80=9Crequest=E2= =80=9D message in the clear, it records the information and kicks into acti= on to divert subsequent 883 messages from going to the operating system, an= d instead handles the transaction on its own. In parallel with the certific= ate 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 comp= artmentalized 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 keystrok= es are blocked from going to the operating system through a hardware interl= ock. But there are many possible variants here that protocol designers need= not be concerned about. With such a capability, the transaction can be com= pleted without access by neither the operating system nor any resident malw= are. Thus once the credentials submission is complete, then the =E2=80=9Cco= mplete=E2=80=9D message from the server would be allowed to pass through to= the operating system to signify then end of this procedure (so the user-ag= ent/browser would send the initial =E2=80=9Crequest=E2=80=9D, and then see = a =E2=80=9Ccomplete=E2=80=9D =E2=80=93 and therefore skip all the steps tha= t would normally be triggered by the =E2=80=9Ccontinue=E2=80=9D message). = =0A=0A2) Alternatively a sandboxing approach might be attempted. Browser de= velopers 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 developer= s focused on specifically sandboxing just the=C2=A0highly limited=C2=A0CCS = function, they might well achieve a terrific success. And this could be als= o done at the server as well, where a tightly sandboxed capability to stric= tly handle credit card (and like) transactions could apply.=0A=0ASo we star= t to see how a modest variant of our protocol definitions could enable a mu= ch greater level of protection of critical credentials. So for a little eff= ort on our part, we get to claim leadership in solving a much larger issue = =E2=80=93 though others would still have to come through with the harder pa= rt of sandboxing or implementing compartmentalized circuitry. =C2=A0I have = no expertise=C2=A0in sandboxing; my embedded experience tells me the compar= tmentalization approach is viable. In fact, the Zurich Labs of IBM has impl= emented a comparable compartmentalized approach with their ZTIC device (htt= p://www.zurich.ibm.com/ztic/). The ZTIC approach was presented at a WorldCI= S session earlier than my paper and can be considered=0Aas an antecedent to= what I covered at WorldCIS this past summer.=0A=C2=A0=0A(Available at:=C2= =A0=C2=A0http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D628019= 8&isnumber=3D6279697=C2=A0)=0A=C2=A0=0AIncidentally, this could also lead t= o benefits to other protocols like POP and SSH and the like. These protocol= s could also be modified to handle credentials submissions via port 883 in = a way that would also permit protection via compartmentalization or sandbox= ing.=0A=C2=A0=0AI hope this comes across clearly; I=E2=80=99ve tried to cov= er 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=E2=80=99t = clear. I=E2=80=99m happy to expand on any aspect you wish.=0A=C2=A0=0AQuest= ions/comments/next steps?=0A=C2=A0=0AJim McAlear=0AOttawa, Canada=C2=A0 ---851882195-27720059-1354674643=:64480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi All =E2=80=93

Here is the protocol sketch I pr= omised. It turned out to be a little easier and more flexible than I though= t.
 
I= =E2=80=99ll first cover how the protocol might operate with a conventional = browser/user-agent, and then cover how compartmentalization or sandboxing w= ould come into play. In this way we can clearly see where our protocol defi= nition job would be separated from an implementer=E2=80=99s job. It could also lead to bene= fits to other protocols.
 
I=E2=80=99ll start with a situation where = a server wishes the user to perform a critical credentials submission (CCS)= =E2=80=93 such as for a credit card transaction (but could alternatively c= over the submission of a Social Security Number, a Passport number or any n= umber of things that should be protected from identity theft). In this situ= ation, the server would send the client a variant of a HTTP 401 message, wh= ich would include as a parameter: a session identifier string. The implicat= ion of the variant message would be that the user-agent would need to open up a new H= TTPS-like session to the server on a well-defined port =E2=80=93 say port 8= 83 for the sake of argument. But the HTTPS-like session would first start w= ith a request-response exchange in the clear; the =E2=80=9Crequest=E2=80=9D= 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) an= d finally the session identifier string such that this session can be assoc= iated with the original session at the server end. (Since a proxy may be in= volved, we can=E2=80=99t rely on an identical client IP address.) The DNS s= tring would be needed if the server runs independent services on it. The = =E2=80=9Cresponse=E2=80=9D message from the server would just be a =E2=80= =9Ccontinue=E2=80=9D message. When the user-agent receives the =E2=80=9Ccon= tinue=E2=80=9D message, then a conventional HTTPS session set-up would foll= ow on this port 883. But underneath this session on port 883 would not be general HTML etc., but just a credentials request transac= tion. This credentials request would be more general than the normal user-i= d/password combination, to allow the server to specify a number of requeste= d fields =E2=80=93 e.g. for a credit card, the server could provide a purch= ase summary and ask for: a) card number, b) expiry date, c) name as shown o= n card, and d) card security code (on back of card). Once this exchange wou= ld be completed, then the HTTPS aspect would close, and a final =E2=80=9Cco= mplete=E2=80=9D message would be sent in the clear from the server to the c= lient. (Additionally, a variant of this could also be defined for the handl= ing of shared-secret/passwords which could employ strong hashing rather tha= n encryption).
 
So this protocol definition doesn=E2=80=99t deviate very much= from capabilities already in our larger set; for browser developers t= he core code needed to implement this might well be completed in a day= or so (not including documentation, verification etc.).
<= div style=3D"color: rgb(0, 0, 0); font-family: times new roman, new york, t= imes, serif; font-size: 13.33px; font-style: normal; background-color: tran= sparent;"> 
=
But now consider h= ow 1) compartmentalization or 2) sandboxing could be applied.
 
1) Consider a compartm= entalized set of circuitry residing on the Network Interface Card of the cl= ient that is unreachable from the operating system, whose sole job is to mo= nitor and interact with packets/messages on server port 883.  When thi= s circuitry sees the first outgoing =E2=80=9Crequest=E2=80=9D message in th= e clear, it records the information and kicks into action to divert subsequ= ent 883 messages from going to the operating system, and instead handles th= e transaction on its own. In parallel with the certificate checking and key exchange, th= e circuitry could look-up the DNS entry of the server string (e.g. buy.merc= hantx.com) to confirm consistency with the IP address of the intender serve= r (it could use the client port already on hold for talking to the server o= n port 883) . It is presumed that the compartmentalized circuitry has somet= hing akin to an independent connection to the user keyboard, which also has= an embedded display, such that when the compartmentalized circuitry prompt= s the user for action, that all keystrokes are blocked from going to the op= erating system through a hardware interlock. But there are many possible va= riants here that protocol designers need not be concerned about. With such = a capability, the transaction can be completed without access by neither th= e operating system nor any resident malware. Thus once the credentials subm= ission is complete, then the =E2=80=9Ccomplete=E2=80=9D message from the se= rver would be allowed to pass through to the operating system to signify then e= nd of this procedure (so the user-agent/browser would send the initial =E2= =80=9Crequest=E2=80=9D, and then see a =E2=80=9Ccomplete=E2=80=9D =E2=80=93= and therefore skip all the steps that would normally be triggered by the = =E2=80=9Ccontinue=E2=80=9D message).
2) Alternatively a sandboxing approach = might be attempted. Browser developers have had some success with sandboxin= g Java and browser operations in general, but the sheer complexity of moder= n 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 handl= e credit card (and like) transactions could apply.
So we start to see how a m= odest 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 =E2=80=93 though= others would still have to come through with the harder part of sandboxing= or implementing compartmentalized circuitry.  I have no expertise&nbs= p;in sandboxing; my embedded experience tells me the compartmentalization a= pproach is viable. In fact, the Zurich Labs of IBM has implemented a compar= able compartmentalized approach with their ZTIC device (http://www.zurich.ibm.com/ztic/). The ZTIC approach was presen= ted at a WorldCIS session earlier than my paper and can be considered
as= an antecedent to what I covered at WorldCIS this past summer.
=
 
 
Incidentally, = this could also lead to benefits to other protocols like POP and SSH and th= e like. These protocols could also be modified to handle credentials submis= sions via port 883 in a way that would also permit protection via compartme= ntalization or sandboxing.
 
I hope this comes across clearly; I=E2=80=99ve tried to cover = the main aspects of operation without bogging down in details, but a one-wa= y exposition is never perfect, so let me know if anything isn=E2=80=99t cle= ar. I=E2=80=99m happy to expand on any aspect you wish.
 = ;
Questions/c= omments/next steps?
Jim McAlear
Ottawa, Canada
 
---851882195-27720059-1354674643=:64480-- From jim.mcalear@rogers.com Tue Dec 11 17:40:51 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1A421E80BA for ; Tue, 11 Dec 2012 17:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBOGMyt-5a-Y for ; Tue, 11 Dec 2012 17:40:50 -0800 (PST) Received: from nm13-vm2.bullet.mail.ne1.yahoo.com (nm13-vm2.bullet.mail.ne1.yahoo.com [98.138.91.89]) by ietfa.amsl.com (Postfix) with ESMTP id AA80521E8096 for ; Tue, 11 Dec 2012 17:40:49 -0800 (PST) Received: from [98.138.90.51] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 12 Dec 2012 01:40:44 -0000 Received: from [98.138.89.170] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 12 Dec 2012 01:40:44 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 12 Dec 2012 01:40:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 286724.76128.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 91997 invoked by uid 60001); 12 Dec 2012 01:40:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1355276444; bh=6UK7GrrmbRLxyNKeK/ArByMkF4rgonDshcxpDfALRT4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MGPfWw9tecHweBR3tlfelAXvhREbuEE56g7EWonqkuKowl8PijHE3+SYUMhU7Fn7W19EqqWQW1q1Jpc6Ruo3x6OKbryWkSv5L4Mp8Mq57hsk+PVjJBAzhRnTFfHGOsxGPmqWocT1WLwMUx1ycE1lNCcxszDPhqMRJu/o7QriEmU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=eoEr11AmttrZ1xdPM+JFKBaNdwcCqG1yDsNmX84YxHFr4gsq7oaLafPy+YHalmgqOSVG+WX8J4UptQKnno9yT90qD7lqHVy/krWPov5jxiPj1Drd6Qr6bQK2GolhSVP33grAoMQukPO6ZuW0DXyxi2R/dyvAXKQ26HmOmJtZTYk=; X-YMail-OSG: rANb_l4VM1lLw6aVwgZagqnU3d7rwxi84HKvmYy9V46mXHw qewB8glcDTVkZa.5YjPpgTHetFI8XRkGzSmIDrCwNiH0s.SLD_TsMnAWB5yX umVVgmka1M1sB5wLoMzTyYORlV4JjU9SOTNnuLGe64dFsq8BeqaIhO1Ggyab 5KULdVmHcqAt9Yz.lUSib_Sa0h9u6EAaRLBxLZ5tqF7crkxSU3ecr9g4HHh1 Xwx9wiWIM2P9DOb7uCwHlcHPEJZofBV.hA4eAUP_tx6N5rUUzpbfqtLopUEB G9hlnPEDEFwbEnFG.XMMdudcjWzIoTE8jvUu0Y.zij5nzEKsOMR6XYOxgehF ueg4AzQ1mTXyGJkKzYFVIyrBTkwIPMYKNJDpttedUig8fdY2GzBhDHE7_P7v a5A95WG4jtzVRbJ3YlU5zCzV7hOUXIHHtr4d5HR2HQAL0Q.aNG1m9S0NdJEi 2BD8w9dVuiu9O1b_EH3qWBvjq8taxgTJV5CTt0hiMzn5hFnZpmFh2foLG8no 6B6tLhJCmSexL.Kd.yxJfklwTv5LwBy03Ne2Jx6O4yR6zo3HODLNxyrHWobD IUtMhP6bV1Oby0bav9el1BaOVbj6u.rmx452uGl_yXASNPPQ48scmCbucsdI APxDKjqoH1Zs- Received: from [99.245.236.70] by web122101.mail.ne1.yahoo.com via HTTP; Tue, 11 Dec 2012 17:40:43 PST X-Rocket-MIMEInfo: 001.001, SGkgQWxsIC0KwqAKSSBob3BlIHdoYXQgSSBzZW50IG91dCBsYXN0IHdlZWsgd2FzIHJlbGF0aXZlbHkgY2xlYXIgLSB3ZSBoYXZlIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIG1ha2Ugc29tZSByZWxhdGl2ZWx5IHNtYWxsIGNoYW5nZXMgdG8gb3VyIHByb3RvY29sIHN1aXRlIHRoYXQgd2lsbCBvcGVuIHVwIHZhbHVhYmxlIG5ldyBvcHRpb25zIGZvciBsb2NhbCBob3N0IHNlY3VyaXR5IHRvIHN0cm9uZ2x5IHByb3RlY3QgdXNlcnMgYWdhaW5zdCB2aWN0aW1pemVycy4KwqAKQnkgY29tcGFydG1lbnRhbGl6aW4BMAEBAQE- X-RocketYMMF: jim.mcalear@rogers.com X-Mailer: YahooMailWebService/0.8.128.478 References: <1354674643.64480.YahooMailNeo@web122104.mail.ne1.yahoo.com> Message-ID: <1355276443.86602.YahooMailNeo@web122101.mail.ne1.yahoo.com> Date: Tue, 11 Dec 2012 17:40:43 -0800 (PST) From: Jim McAlear To: "http-auth@ietf.org" In-Reply-To: <1354674643.64480.YahooMailNeo@web122104.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1593584224-1304784350-1355276443=:86602" Subject: [http-auth] Moving forward on protocol variant for secure credentials submission X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jim McAlear List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 01:40:51 -0000 ---1593584224-1304784350-1355276443=:86602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All -=0A=C2=A0=0AI 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 securi= ty to strongly protect users against victimizers.=0A=C2=A0=0ABy compartment= alizing 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 ide= ntity theft. As described, the changes would require just minor efforts on = the part of browser developers and server framework developers and=C2=A0min= or efforts in redefining our protocols. And with such changes, compartmenta= lization or sandboxing could be applied at either, or both, ends of a conne= ction and deliver valuable benefits in part or in whole. And for users, nob= ody would have to reach for a different device (e.g. mobile phone, smart ca= rd etc.) nor be required to=C2=A0enter additional information that he other= wise=C2=A0would have; the solution has the flexibility to allow the user to= use the normal keyboard capability of the client device.=C2=A0It can also = lead to benefits for applications that utilize other protocols - e.g. POP, SSH and more. =0A=C2=A0=0AA common convention is that silence means c= onsent, 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 ins= ertion into an RFC.=0A=C2=A0=0AI expect that the material will be comprised= of: 1) objectives, 2) description of a possible, but not proscibed,=C2=A0h= ardware reference description that allows compartmentalization of=C2=A0auth= entication transactions, =C2=A03) protocol overview, 4) protocol details fo= r secure credentials submission and 5) protocol details for shared-secret h= ashing submission. Given that the holiday season has started, with all the:= get-togethers, errands, traveling and more, I don't expect to get much don= e until January. Even then, I'm expecting that I'll put out a draft in sect= ions/stages.=0A=C2=A0=0ASo again, if there are any concerns, issues or sugg= estions, please let me know. Help is also very welcome; this could be an im= portant turning point in protecting users from cyber-criminals - it will be= =C2=A0critical to get things right.=0A=C2=A0=0A- Jim McAlear=0AOttawa, Cana= da=0A =0A----- Forwarded Message -----=0AFrom: Jim McAlear =0ATo: "http-auth@ietf.org" =0ASent: Tuesday, De= cember 4, 2012 9:30:43 PM=0ASubject: Sketch or protocol for secure credenti= als submission & opening up new options for local security=0A =0A=0AHi All= =E2=80=93=0A=0AHere is the protocol sketch I promised. It turned out to be= a little easier and more flexible than I thought.=0A=C2=A0=0AI=E2=80=99ll = first cover how the protocol might operate with a conventional browser/user= -agent, and then cover how compartmentalization or sandboxing would come in= to play. In this way we can clearly see where our protocol definition job w= ould be separated from an implementer=E2=80=99s job. It could also lead to = benefits to other protocols.=0A=0AI=E2=80=99ll start with a situation where= a server wishes the user to perform a critical credentials submission (CCS= ) =E2=80=93 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 sit= uation, the server would send the client a variant of a HTTP 401 message, w= hich would include as a parameter: a session identifier string. The implica= tion 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 =E2=80=93= say port 883 for the sake of argument. But the HTTPS-like session would fi= rst start with a request-response exchange in the clear; the =E2=80=9Creque= st=E2=80=9D message would have a header indicating a CCS message, and then = a field to indicate the originating service DNS identifier (e.g. buy.mercha= ntx.com) and finally the session identifier string such that this session can be associated with the original session at the serve= r end. (Since a proxy may be involved, we can=E2=80=99t rely on an identica= l client IP address.) The DNS string would be needed if the server runs ind= ependent services on it. The =E2=80=9Cresponse=E2=80=9D message from the se= rver would just be a =E2=80=9Ccontinue=E2=80=9D message. When the user-agen= t receives the =E2=80=9Ccontinue=E2=80=9D message, then a conventional HTTP= S 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 norma= l user-id/password combination, to allow the server to specify a number of = requested fields =E2=80=93 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 exch= ange would be completed, then the HTTPS aspect would close, and a final =E2=80=9Ccomplete=E2=80=9D message would b= e 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).=0A=C2=A0=0ASo th= is protocol definition doesn=E2=80=99t deviate very much from capabilities = already in our larger=C2=A0set; for browser developers the core code needed= to implement this=C2=A0might well be completed in a day or so=C2=A0(not in= cluding documentation, verification etc.).=0A=C2=A0=0ABut now consider how = 1) compartmentalization or 2) sandboxing could be applied. =0A=C2=A0=0A1) C= onsider a compartmentalized set of circuitry residing on the Network Interf= ace 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 8= 83. =C2=A0When this circuitry sees the first outgoing =E2=80=9Crequest=E2= =80=9D message in the clear, it records the information and kicks into acti= on to divert subsequent 883 messages from going to the operating system, an= d instead handles the transaction on its own. In parallel with the certific= ate 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 comp= artmentalized 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 keystrok= es are blocked from going to the operating system through a hardware interl= ock. But there are many possible variants here that protocol designers need= not be concerned about. With such a capability, the transaction can be com= pleted without access by neither the operating system nor any resident malw= are. Thus once the credentials submission is complete, then the =E2=80=9Cco= mplete=E2=80=9D message from the server would be allowed to pass through to= the operating system to signify then end of this procedure (so the user-ag= ent/browser would send the initial =E2=80=9Crequest=E2=80=9D, and then see = a =E2=80=9Ccomplete=E2=80=9D =E2=80=93 and therefore skip all the steps tha= t would normally be triggered by the =E2=80=9Ccontinue=E2=80=9D message). = =0A=0A2) Alternatively a sandboxing approach might be attempted. Browser de= velopers 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 developer= s focused on specifically sandboxing just the=C2=A0highly limited=C2=A0CCS = function, they might well achieve a terrific success. And this could be als= o done at the server as well, where a tightly sandboxed capability to stric= tly handle credit card (and like) transactions could apply.=0A=0ASo we star= t to see how a modest variant of our protocol definitions could enable a mu= ch greater level of protection of critical credentials. So for a little eff= ort on our part, we get to claim leadership in solving a much larger issue = =E2=80=93 though others would still have to come through with the harder pa= rt of sandboxing or implementing compartmentalized circuitry. =C2=A0I have = no expertise=C2=A0in sandboxing; my embedded experience tells me the compar= tmentalization approach is viable. In fact, the Zurich Labs of IBM has impl= emented a comparable compartmentalized approach with their ZTIC device (htt= p://www.zurich.ibm.com/ztic/). The ZTIC approach was presented at a WorldCI= S session earlier than my paper and can be considered=0Aas an antecedent to= what I covered at WorldCIS this past summer.=0A=C2=A0=0A(Available at:=C2= =A0=C2=A0http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D628019= 8&isnumber=3D6279697=C2=A0)=0A=C2=A0=0AIncidentally, this could also lead t= o benefits to other protocols like POP and SSH and the like. These protocol= s could also be modified to handle credentials submissions via port 883 in = a way that would also permit protection via compartmentalization or sandbox= ing.=0A=C2=A0=0AI hope this comes across clearly; I=E2=80=99ve tried to cov= er 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=E2=80=99t = clear. I=E2=80=99m happy to expand on any aspect you wish.=0A=0AQuestions/c= omments/next steps?=0A=C2=A0=0AJim McAlear=0AOttawa, Canada=C2=A0 ---1593584224-1304784350-1355276443=:86602 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi All -
 
I hope what I sent out last week was r= elatively clear - we have a unique opportunity to make some relatively smal= l 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/authen= tication transactions within our protocols, it can allow local security eff= orts to cleanly do the same to support protection of critical credentials t= hat are so often exploited for cyber-crime and identity theft. As described= , the changes would require just minor efforts on the part of browser devel= opers and server framework developers and minor efforts in redefining = our protocols. And with such changes, compartmentalization or sandboxing co= uld be applied at either, or both, ends of a connection and deliver valuabl= e benefits in part or in whole. And for users, nobody would have to reach f= or 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 benefit= s for applications that utilize other protocols - e.g. POP, SSH and more. <= /span>
 
A common convention is that = silence means consent, so if you have any concerns or issues with this, ple= ase let me know. Otherwise I will get started on preparing a draft of the m= aterial for insertion into an RFC.
 
<= div style=3D"color: rgb(0, 0, 0); font-family: verdana, helvetica, sans-serif; font-size: 13.33px; font-style: normal; background-color: tran= sparent;">I expect that the material will be comprised of: 1) objecti= ves, 2) description of a possible, but not proscibed, hardware referen= ce description that allows compartmentalization of authentication tran= sactions,  3) protocol overview, 4) protocol details for secure creden= tials submission and 5) protocol details for shared-secret hashing submissi= on. 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 the= re are any concerns, issues or suggestions, please let me know. Help is als= o very welcome; this could be an important turning point in protecting user= s from cyber-criminals - it will be critical to get things right.
 
- Jim McAlear
Ottawa, Canada

----- Forwarded Message -----
= From: Jim McAlear <jim.mca= lear@ieee.org>
To: = "http-auth@ietf.org" <http-auth@ietf.org>
Sent: Tuesday, December 4, 2012 9:30:43 PM
<= b>Subject: Sketch or protocol= for secure credentials submission & opening up new options for local s= ecurity

Hi All =E2=80=93

Here is the protocol sketch I= promised. It turned out to be a little easier and more flexible than I thought.
 
I=E2=80=99ll first cover how the protocol might operate with a convent= ional browser/user-agent, and then cover how compartmentalization or sandbo= xing would come into play. In this way we can clearly see where our protoco= l definition job would=0A be separated from an implementer=E2=80=99s job. I= t could also lead to benefits to other protocols.
 
I=E2=80=99ll star= t with a situation where a server wishes the user to perform a critical cre= dentials submission (CCS) =E2=80=93 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 iden= tity 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 identi= fier string. The implication of the=0A variant message would be that the us= er-agent would need to open up a new HTTPS-like session to the server on a = well-defined port =E2=80=93 say port 883 for the sake of argument. But the = HTTPS-like session would first start with a request-response exchange in th= e clear; the =E2=80=9Crequest=E2=80=9D message would have a header indicati= ng a CCS message, and then a field to indicate the originating service DNS = identifier (e.g. buy.merchantx.com) and finally the session identifier stri= ng such that this session can be associated with the original session at th= e server end. (Since a proxy may be involved, we can=E2=80=99t rely on an i= dentical client IP address.) The DNS string would be needed if the server r= uns independent services on it. The =E2=80=9Cresponse=E2=80=9D message from= the server would just be a =E2=80=9Ccontinue=E2=80=9D message. When the us= er-agent receives the =E2=80=9Ccontinue=E2=80=9D message, then a convention= al HTTPS session set-up would follow on this port 883. But underneath this = session on port=0A 883 would not be general HTML etc., but just a credentia= ls 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 =E2=80=93 e.g. for a credit card, the server cou= ld 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 =E2=80=9Ccomplete=E2=80=9D message would be sent in the clear from t= he server to the client. (Additionally, a variant of this could also be def= ined for the handling of shared-secret/passwords which could employ strong = hashing rather than encryption).
 
So this protocol definition doesn=E2=80=99t deviate very much= from capabilities already in our larger set; for browser developers t= he core code needed to implement this might well be completed in a day= or so (not including documentation, verification etc.).
<= div style=3D"color: rgb(0, 0, 0); font-family: times new roman, new york, t= imes, serif; font-size: 13.33px; font-style: normal; background-color: tran= sparent;"> 
=
But now consider h= ow 1)=0A compartmentalization or 2) sandboxing could be applied.
 
1) Consider a = compartmentalized set of circuitry residing on the Network Interface Card o= f 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 =E2=80=9Crequest=E2=80=9D messa= ge in the clear, it records the information and kicks into action to divert= subsequent 883 messages from going to the operating system, and instead ha= ndles the transaction=0A on its own. In parallel with the certificate check= ing and key exchange, the circuitry could look-up the DNS entry of the serv= er string (e.g. buy.merchantx.com) to confirm consistency with the IP addre= ss 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 compartmental= ized circuitry has something akin to an independent connection to the user = keyboard, which also has an embedded display, such that when the compartmen= talized circuitry prompts the user for action, that all keystrokes are bloc= ked from going to the operating system through a hardware interlock. But th= ere are many possible variants here that protocol designers need not be con= cerned about. With such a capability, the transaction can be completed with= out access by neither the operating system nor any resident malware. Thus o= nce the credentials submission is complete, then the =E2=80=9Ccomplete=E2= =80=9D message from the server=0A would be allowed to pass through to the o= perating system to signify then end of this procedure (so the user-agent/br= owser would send the initial =E2=80=9Crequest=E2=80=9D, and then see a =E2= =80=9Ccomplete=E2=80=9D =E2=80=93 and therefore skip all the steps that wou= ld normally be triggered by the =E2=80=9Ccontinue=E2=80=9D message).
2) Alte= rnatively a sandboxing approach might be attempted. Browser developers have= had some success with sandboxing Java and browser operations in general, b= ut 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, the= y might well achieve a terrific success. And this could be also done at=0A = 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 mo= dest 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 =E2=80=93 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 ap= proach is viable. In fact, the Zurich Labs of IBM has implemented a compara= ble compartmentalized approach with their ZTIC device (http://www.zurich.ibm.com/z= tic/). The ZTIC ap= proach 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 sum= mer.
&= nbsp;
 
Incidentally, = this could also lead to benefits to other protocols like POP and SSH and th= e like. These protocols could also be modified to handle credentials submis= sions via port 883 in a way that would also permit protection via compartme= ntalization or sandboxing.
 
I hope this comes across clearly; I=E2=80=99ve tried to cover = the main aspects of operation without bogging down in details, but a one-wa= y exposition is never perfect, so let me know if anything isn=E2=80=99t cle= ar. I=E2=80=99m happy to expand on any aspect you wish.
 = ;
Questions/c= omments/next=0A steps?
 
Jim McAlear
Ottawa, Canada
 
=

---1593584224-1304784350-1355276443=:86602--