From stephen.farrell@cs.tcd.ie Sun Jan 13 09:36:14 2013 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 1FD4121F8824 for ; Sun, 13 Jan 2013 09:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 wTftwyIfN+50 for ; Sun, 13 Jan 2013 09:36:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAEF21F87C5 for ; Sun, 13 Jan 2013 09:36:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 68738BE3B for ; Sun, 13 Jan 2013 17:35:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc+Ui-R7c1F6 for ; Sun, 13 Jan 2013 17:35:50 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.42.21.48]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AD7DBE38 for ; Sun, 13 Jan 2013 17:35:50 +0000 (GMT) Message-ID: <50F2F075.8090809@cs.tcd.ie> Date: Sun, 13 Jan 2013 17:35:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.5 Content-Type: multipart/mixed; boundary="------------030709020000050405010409" Subject: [http-auth] charter rev -03 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: Sun, 13 Jan 2013 17:36:14 -0000 This is a multi-part message in MIME format. --------------030709020000050405010409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all and happy new year, Sorry to have done nothing since mid-Nov on this, but I've finally gotten around to going back over the list traffic and modified the text to make the attached -03 version of the charter. I think this one is good enough to hand over to Sean to see what he wants to do about it, that is, I don't see it getting way way better due to mail on this list, so I reckon we're done for now, and its over to Sean to see what he thinks. Cheers, S. --------------030709020000050405010409 Content-Type: text/plain; charset=UTF-8; name="ha-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ha-03.txt" 2013-01-13, -03 HTTP authentication is currently used for user authentication by few web sites. Form-based or "web" authentication is much more commonly used. Only the former is in scope here, the latter is out of scope. The httpauth WG will be a short-lived working group that will document a small number of HTTP user authentication schemes that might offer security benefits, and that could, following experimentation, be widely adopted as standards-track schemes for HTTP user authentication. Each of the RFCs produced should include a description of when it is appropriate to be used, e.g. via a use-case or other distinguising characteristics. All schemes to be developed in the httpauth WG must be usable with the existing HTTP authentication framework, or with evolutions of that framework as developed in the httpbis WG. That is, the evolution of the HTTP authentication framework is to be done in the httpbis WG and not in the httpauth WG. The httpauth WG will work closely with the httpbis WG to ensure that the outcomes from the httpauth WG do not conflict with work done elsewhere. The starting points for work will be: - draft-williams-http-rest-auth - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension - draft-farrell-httpbis-hoba - draft-montenegro-httpbis-multilegged-auth - draft-melnikov-httpbis-scram-auth In addition, the WG will aim to get rough consensus on two drafts that will obsolete the basic and digest schemes defined in RFC 2617 taking into account errata on that specification. For the digest scheme, "more modern" algorithm agility and internationalisation support will be developed as a standards-track RFC. The starting point for this will be draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded from e.g. adding a Diffie-Hellman exchange to this method. For the basic scheme, no technical changes are envisaged other than to handle i18n of usernames and passwords, the goal will simply be to improve the documentation of the scheme to allow obsoleting RFC 2617 which has some significant flaws when looked back at 13 years later. Other than the documents that aim to obsolete RFC 2617, the rest of the WG output will be a set of informational or experimental RFCs. Other than obsoleting RFC 2617 developing standards track solutions is out of scope as none of the proposals are expected to be sufficiently widely deployed to warrant that status before the WG closes. The WG is not required to merge all proposals into one. The goal is not that participants reach rough consensus on every proposal, but rather to review and improve proposals and to quickly produce stable specifications and then close. It is expected that the market/community will select which if any of the RFCs developed might be worth progressing on the standards-track at a later date, in a different WG. Adoption of additional work items is not expected and will require a re-charter. The following are explicitly out of scope: - changes to TLS - changes to HTTP, however, if some change is proposed that is clearly supported by the httpbis WG then that would be fine, for example, one might envisage that a new HTTP header field might be acceptable if both this and the httpbis wg had rough consensus for the addition of that header field, albeit that working solely within the existing authentication framework is preferable to defining new header fields - definition of authentication mechanisms that do not work with the HTTP authentication framework - authentication schemes that distinguish between devices and humans or for components of web services, and that cannot be sensibly used for humans, for example device state authentication such as done by the NEA wg is out of scope - "web" authentication that is not HTTP authentication Milestones: - TBD --------------030709020000050405010409-- From y.oiwa@aist.go.jp Wed Jan 23 16:37:36 2013 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 5DCD621F85AC for ; Wed, 23 Jan 2013 16:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 60ku5eI+HoR8 for ; Wed, 23 Jan 2013 16:37:35 -0800 (PST) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2621F859D for ; Wed, 23 Jan 2013 16:37:35 -0800 (PST) Received: from mail-qc0-f199.google.com ([209.85.216.199]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUQCCTt1yDxYlPNroO4lXutKEppsRfCWT@postini.com; Wed, 23 Jan 2013 16:37:35 PST Received: by mail-qc0-f199.google.com with SMTP id b14so7809081qcs.6 for ; Wed, 23 Jan 2013 16:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wvBLGOmtA6g2bjXC9TDJP23GAKRk49ona2Do7xN5WZM=; b=bAIJG8QBw0RV6k3eJ94pYOseCMhP9s88zmlf0MFuNAEfiV5zrzMvj3SJM4lF4E16co opm3coztQV/RMeNKJfhQqb9xLHzc3y3I+A5gvARcP/UOGyGmRMjsvce3YaKrmLH95ae4 YokUSXBFl02qcmr6l6EA8NtSNZnOBARDkClPk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=wvBLGOmtA6g2bjXC9TDJP23GAKRk49ona2Do7xN5WZM=; b=Piw6ZLVL28N1QWzKsN4wcR4ydYNyCQSDvWHF+1DtWvH0ojcnoPMLeNWFSDWB1F/I8w 2LV++JkO6aY16B9SuTfVCokPmg9VSZrxx4O6yhniOq29rBtaeh9bz+ve2OogssLpSCtQ ER8XiGccXruDFV2DambcvDEsOYwvheK7ia7ZE5bIHjQAH08Y2xq63wXefcmJbnEntut8 vEsJSPRDnsiMXCttMs6oSRYknZZss77rTEjVl2LsWlHxgM6F8IKo1qand8SvuDKIWxdm qe3ad8GcKWnhSk9pqn/gNSZR8gFj4sZ83asqS/3s6JYoUfSY+qWIAACQJpxkhR0Gtxq4 T6+A== X-Received: by 10.52.33.143 with SMTP id r15mr64264vdi.78.1358987854184; Wed, 23 Jan 2013 16:37:34 -0800 (PST) X-Received: by 10.52.33.143 with SMTP id r15mr64257vdi.78.1358987853980; Wed, 23 Jan 2013 16:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.164.37 with HTTP; Wed, 23 Jan 2013 16:37:13 -0800 (PST) In-Reply-To: <50F2F075.8090809@cs.tcd.ie> References: <50F2F075.8090809@cs.tcd.ie> From: Yutaka OIWA Date: Thu, 24 Jan 2013 09:37:13 +0900 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkLScuNlyltpPobz5RwgTi6WeU0xufWRbrOuBG3KzqIdTy3Oep7tHTfb1p2g8lfu5bqBNgUgauvpuPZXNV40zfOoR2vW3HlXo6yw6IchsUumFxHo7LYreChjmp2v8c1bo9vxdfQsuxBgMLyM6ZUALYLbyp9/Q== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 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: Thu, 24 Jan 2013 00:37:36 -0000 Dear All, I think it's the best text at this moment, thank you Stephen. I'd like to go on improving our current proposal. I will be happy if we can have some (bar-style?) meeting-up during the next meeting period, to share how the things go in a face-to-face manner. Also, as our proposal I-Ds are (technically) expired, we will submit a maintenance revision sooner to make it alive. I have received a few improvement suggestions since the last meeting, and I'd like to ask people for some more inputs regarding such suggestions. I will send some separate mails for such issues to this mailing list soon. Thanks, Yutaka 2013/1/14 Stephen Farrell : > > Hi all and happy new year, > > Sorry to have done nothing since mid-Nov on this, but I've > finally gotten around to going back over the list traffic > and modified the text to make the attached -03 version of > the charter. > > I think this one is good enough to hand over to Sean to see > what he wants to do about it, that is, I don't see it getting > way way better due to mail on this list, so I reckon we're > done for now, and its over to Sean to see what he thinks. > > Cheers, > S. > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From jim.mcalear@rogers.com Sat Jan 26 16:58:14 2013 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 53BEB21F8801 for ; Sat, 26 Jan 2013 16:58:14 -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 IfBFZSXRUsHG for ; Sat, 26 Jan 2013 16:58:11 -0800 (PST) Received: from nm30-vm3.bullet.mail.ne1.yahoo.com (nm30-vm3.bullet.mail.ne1.yahoo.com [98.138.91.160]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2B21F8721 for ; Sat, 26 Jan 2013 16:58:11 -0800 (PST) Received: from [98.138.226.176] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jan 2013 00:58:03 -0000 Received: from [98.138.89.245] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 27 Jan 2013 00:58:03 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 27 Jan 2013 00:58:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 862468.30737.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 96395 invoked by uid 60001); 27 Jan 2013 00:58:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1359248283; bh=q6b7+UgwW4dEWt2n/50P/DwQ+h5dOQ16rEB06FvIn8s=; 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=fVFKmR+FY6KKZ2Jp3v2l5WQcGo/8Hv+jEVHG3vNdCpdmH67xgaStPxLzoi2/clXLNowpR03+CKqdFlWreOvhN9LXDNpv/96Dax7xnIrz8UOceBAr0kePb8TCGmb1Dnm5c9yQHnZdHkGsSfN+8Oictfdww4fYWgxB8gQey8vFx2Q= 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=rUeDIO3jdDILyLvPLEcw5LaBjU3ANAnuYP7+C4kqB0mYmbcImJ4S38Fy5tiriyOJPDEjBD3x5bDfnX6+V2TSiOMrx4golF8v+76x4l2SazTU4fin6Kyp07PXnY7QwOQhqyR0Sc0AyI6KGLdgDp5a4RNxyt+Prft/iMsLdIc1ugs=; X-YMail-OSG: 0_QolA0VM1kQM7g.VZOa7woBnTfEtmSflK7htra.SE3RWvq 3McClUPXIpbAfYtFSIhqvDI110JLE8Exiaw9ikbAV9vHLglRtjwhT45xWaFq mECYKugrMnVvaugXPthM15xVTnBXgebsedubw8PQQaxFoVO_UFZWOwbSKd_U 3XiAmF2oIqgYgCF7O.SU1szyfcBCS_e1p_K9UbZtRH6Q0_WXU8b.e9guY9Rg m9nCYbLOI.1SDQnq.meLdE07nZbsB3OFpjtcTqeipDypFjkwR0ZTFCIfog6X rJLVzonmPUKVq7KhY_PGsMRKS1xZL704OksVpAozLxGX2p7WjTSCMtCYBvc6 Hp9XKutq4QI1T6Pb.2BZHcfFBYbc2PqjhcGcl9KrLSmedoH5QEApePOQgf2g J7dm.Cf2terbDfhK0h6CeU_9v6OwsDspPKEtkDfMWjylkLJG4ww5iJoBARs8 H1ZzvTfPpZjvHdeKaLjI25_Biq.0cc6Db7KDnC9JJ2BO98xNanMl7.x_jT6W nKqbp4yxjlR6ruahogTzZcf9r9cCFmD_uI6.aHp4xV5EiCdhdWUU- Received: from [99.245.236.70] by web122104.mail.ne1.yahoo.com via HTTP; Sat, 26 Jan 2013 16:58:03 PST X-Rocket-MIMEInfo: 001.001, SGkgQWxsIOKAkwpBdHRhY2hlZCBpcyB0aGUgZmlyc3Qgb3V0bGluZSBvZiB0aGUgSFRUUC1BdXRoIHN1Ym1pc3Npb24gSQpwcm9taXNlZCBsYXN0IHllYXIuIFRoZXJlIGFyZSBzdGlsbCBxdWl0ZSBhIGZldyBkZXRhaWxzIHRoYXQgbmVlZCB0byBiZSBwaW5uZWQKZG93biwgYnV0IHRoZXJlIGlzIGVub3VnaCBvZiBhIGhpZ2ggbGV2ZWwgc3BlY2lmaWNhdGlvbiB0byBzaGFrZSBvdXQgYW55IHRvcApsZXZlbCBpbXBsZW1lbnRhdGlvbiBvciBjb21wYXRpYmlsaXR5IGNvbmNlcm5zLiBJIGhhdmUgcHJvdmlkZWQBMAEBAQE- X-RocketYMMF: jim.mcalear@rogers.com X-Mailer: YahooMailWebService/0.8.130.494 Message-ID: <1359248283.95780.YahooMailNeo@web122104.mail.ne1.yahoo.com> Date: Sat, 26 Jan 2013 16:58:03 -0800 (PST) From: Jim McAlear To: "http-auth@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-851882195-2051486450-1359248283=:95780" Subject: [http-auth] Proposal for HTTP credentials handling side session 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, 27 Jan 2013 00:58:14 -0000 ---851882195-2051486450-1359248283=:95780 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All =E2=80=93=0AAttached is the first outline of the HTTP-Auth submissio= n I=0Apromised last year. There are still quite a few details that need to = be pinned=0Adown, but there is enough of a high level specification to shak= e out any top=0Alevel implementation or compatibility concerns. I have prov= ided some quick=0Aoutlines for some details sections in order to preview ne= eded refinements. Finally,=0Aat the end I=E2=80=99ve included an open-ended= question on how this kind of approach=0Acould add value to other protocols= and capabilities within internet systems.=0AQuestions/comments? =0AThanks = in advance for looking at this. I=E2=80=99ll be traveling=0Athis coming wee= k with limited access to email; I=E2=80=99ll be able to handle quick=0Aques= tions, but more complex replies will have to wait until next week.=0AJim Mc= Alear=0AOttawa, Canada=0ATitle: =0ANew Security Options for HTTP Authentica= tion Handling of=0ACredentials and Critical Transactions=0AAbstract: =0AThi= s document defines new options for handling critical=0Acredentials and tran= sactions (that involve the use of passwords, credit card=0Anumbers and more= ) within the HTTP protocol in order to open up new approaches=0Ato providin= g host-level security at clients and servers. These new forms of=0Acredenti= als handling require only minor variations of current HTTP processing=0Acap= abilities of current client and server software stacks; what these variants= =0Aaccomplish, is to layer and structure the protocol details in such a way= that=0Apermits different forms of compartmentalization or sandboxing to ap= ply within=0Ahosts such that these critical transactions can be handled out= side the reach of=0Aall-to-common host-resident malware. Some compartmental= ization examples are=0Aprovided herein; these are meant to be suggestive, n= ot prescriptive, and the=0Astructure of the protocol provides implementers = with a large degree of=0Aflexibility to configure suitably compartmentalize= d or sandboxed solutions at=0Aclients and servers.=0AIntroduction: =0AThe i= ntroduction to the draft HTTP 2.0 protocol=0Aspecification states: HTTP has= been a wildly successful protocol. This is not=0Aonly true from an enginee= ring perspective, but also from that of end-users. So=0Ain contemplating im= provements to this protocol, it is not only appropriate to=0Aengineer effic= iency gains such as SPDY, but to also examine avenues to address=0Akey user= concerns. So while HTTP has been wildly successful in connecting users=0At= o all kinds of desired services, the main shortcoming perceived by users is= susceptibility to various forms of fraud and=0Aidentity theft =E2=80=93 es= pecially due to the theft of critical credentials. Of course=0Athis is much= more than a worry; such crimes are being committed on a massive,=0Aindustr= ial scale and years of countervailing efforts have not successfully stemmed= =0Athis crime wave. The vast majority of these crimes come about due to mal= ware=0Ainfections of host computers; it is well beyond the practical abilit= y of=0Aprotocol developers to delve into this incredibly complex realm to o= ffer=0Ageneral solutions against malware exploitation. =0ABut an opportunit= y has arisen to define a solution that can=0Ahandle critical credentials an= d transactions outside the reach of (presumed)=0Ahost=E2=80=93resident malw= are.=C2=A0 This proposed=0Acontribution will define optional hardware refer= ence configurations for compartmentalized=0Ahandling of key credentials and= transactions, and then proceed to define=0Aprotocol details that enable su= ch secure handling of this critical information.=0AFor maximum host archite= cture compartmentalization flexibility, the reference=0Ahardware compartmen= talization will focus at the point of the host Network=0AInterface Card (or= Component) =E2=80=93 this being the lowest point within the host=0Aarchite= cture operating at the physical layer connection to a network. In this=0Awa= y, if the protocol can support a compartmentalized credentials handling=0Ai= nterdiction at that low point, then other compartmentalized or sandboxed=0A= options are also opened up at higher layers within the host hardware and=0A= software architectures. So the upshot of this proposed contribution is that= it=0Aopens up whole new approaches to host security as far as handling cri= tical=0Acredentials and transactions, though it is up to computer hardware = and software=0Adevelopers to fulfill these within their designs.=0ACompartm= entalization Reference Hardware Configuration: =0AThe reference hardware co= nfiguration defined for this new=0Aspecification concerns new functionality= of the Network Interface Card (or Component=0A=E2=80=93 either way abbrevi= ated as NIC) of a host computer. It is assumed here that=0Athis component h= as an additional outboard interface, a USB port=C2=A0for the sake=0Aof conc= reteness, and new independent functionality to monitor, intercept and=0Aman= ipulate very specific credentials communications that take place across the= =0Anetwork. This outboard port will be accessible to specific circuitry of = the=0ANIC, but not be exposed in any way to the higher layers of host hardw= are nor=0Athe operating system. At the client end of the communication, the= USB port will=0Atypically attach to a keyboard in a way that the user can = enter credentials almost=0Adirectly into the transaction protocol without k= eystrokes going to the host=0Aoperating system (and through any malware ena= bled keystroke-capture capability).=0AMore elaborately, the keyboard would = have an embedded display that operates=0Aindependently of the operating sys= tem, such that the user can view the proposed=0Atransaction/credentials req= uest details and compose a suitable reply if the=0Arequest details are sati= sfactory =E2=80=93 just barely off the connection from the=0Aphysical layer= . This function would be triggered as the result of a=0Awell-defined protoc= ol condition observed in the NIC. When this operation is=0Atriggered, the c= onnected keyboard component will be blocked from sending=0Akeystrokes via t= he conventional connection to the operating system, until the=0Acredentials= transaction has completed or cancelled. At the server end, the USB=0Aport = of the NIC would connect to a USB memory/processor stick containing a=0Adat= abase of user passwords or credit card merchant account information, such= =0Athat credentials transactions can likewise be completed outside the purv= iew of=0Athe host operating system and thus any resident malware. The next = section will=0Acover the essentials of operation with these configurations = =E2=80=93 though an example=0Awill also be provided where the compartmental= ization doesn=E2=80=99t need to be applied=0Aat the NIC level =E2=80=93 thu= s demonstrating the flexibility for host software and=0Ahardware architects= to innovate in the area of compartmentalizing or sandboxing=0Acredentials = transactions away from presumed resident malware. And though this=0Areferen= ce configuration makes mention of a physical keyboards, displays and=0ANICs= and outboard ports, these are by no means prescriptive =E2=80=93 useful=0A= alternatives to these are exposed within a referenced publication [tbd].=0A= Key Protocol Features for Operation with Reference=0AConfigurations:=0AHere= we begin with a situation where an existing HTTP or=0AHTTPS connection has= already been initiated, and the server software reaches a=0Acondition wher= eby it needs a credentials submission by a user =E2=80=93 be it the=0Asubmi= ssion of a password, or a set of credit card parameters, or other=0Asensiti= ve information like a passport number or a Social Security Number. For=0Ath= e most restrictive case, we will assume here that the existing connection i= s=0AHTTPS. At this point we will require the server to send the client a (p= roposed)=0AHTTP 308 Message: Request Credentials Side Session. Within the b= ody of this 308=0Aresponse will be a specification of the intended host (e.= g. buy.example.com)=0Aand a one-time transaction identifier (a pseudo-rando= m alphanumeric string) to=0Aassociate a to-be-created side session with the= original session at the server=0Aend (important for making session associa= tions passing through proxy servers).=0AAt this point the user-agent of at = the client will send out a first message to=0Aa well-defined (proposed) ser= ver port 446 as if a new HTTPS session were to be=0Acreated (this may be do= ne over a new TCP session or a UDP interchange). The=0Alead message will ha= ve the specified host and transaction identifier fields=0Aincluded in the c= lear.=C2=A0 The added NIC=0Abased functionality in the client reference con= figuration would monitor incoming=0Aand outgoing packets to server port 446= and then proceed to intercede and take=0Aover the side session until compl= etion (or cancellation). Thus the client NIC=0Awould then interact with the= server to set up a TLS session, using its own=0Aindependent encryption cap= abilities, and once established the server would=0Aprovide a specification = of an intended transaction and desired user credentials =E2=80=93=0Asuch th= at the compartmentalized functionality of the NIC will then present and=0Ac= ollect these from the user for secure submission to the server. All the whi= le=0Athis is happening, the compartmentalized NIC functionality will block = any=0Apackets to and from server port 446 from ever reaching any other comp= onents of=0Athe host system. It must be noted that this side session must n= ot involve the=0Afull set of HTTP capabilities, but just a very limited int= eraction to allow=0Acredentials transactions. The server cannot know if the= client NIC incorporates=0Athis functionality, for that matter the client u= ser-agent may not have this=0Aknowledge in advance. Thus if the client NIC = does not have this functionality,=0Aor if an enabled NIC notes that a keybo= ard capability has not been connected to=0Athe outboard port, then these 44= 6 messages are passed to the operating system=0Aand user-agent must complet= e the transaction per the details of this=0Aspecification (in the current f= ashion that risks malware access). =0AA complementary process can occur at = the server end. If the=0Aserver NIC has the needed compartmentalized functi= ons that are triggered on=0Aport 446 activity, then this capability is trig= gered to respond to the client=0Arequested side session set-up using its ow= n encryption capabilities and=0Ablocking port 446 messages from reaching th= e upper hardware and software layers=0Aof the server host. The key exceptio= n is that once the compartmentalized NIC=0Acapability has taken over the se= ssion, it will send a message up to the higher=0Alayers of the server using= port 446 and containing the intended host and=0Asession number (in a diffe= rent form than what the client side has sent), to=0Areceive from the higher= layers of the server the required parameters of the=0Atransaction. For a c= redit card transaction, these parameters would normally=0Ainclude the purch= ase details of: amount to charge and shipping address (if=0Aneeded), and th= en a specification for credit card parameters requested =E2=80=93 such=0Aas= card number, expiry date and verification code. Such information would be= =0Asent by the higher layers of the server down to port 446 and be intercep= ted by=0Athe NIC functionality. The NIC would then encapsulate such paramet= ers within=0Athe encrypted session with the client side and await the user = response. Upon=0Areceipt of the user credentials from the client end, the N= IC and USB key=0Afunctionality could then independently contact a credit ca= rd clearance service=0Ato validate the transaction. The transaction success= /fail response and summary=0Acode would then be passed up to the server on = port 446. The details of the=0Atransaction would normally be logged within = the attached USB key for an=0Aindependent record that is inaccessible by an= y server-resident malware. In an=0Aalternative interaction, the USB memory = stick could contain a database of=0Apassword information, and could verify = password submissions without malware=0Ahaving any access to the password da= tabase. Other alternatives are described in=0Aa reference publication [tbd]= .=0AAs discussed earlier, while the protocol definition enables=0Acompartme= ntalization that can operate just above the physical connection to the=0Ane= twork, other options are still viable. In terms of host security - complexi= ty=0Ais the enemy of security. So consider a high volume online storefront = that=0Amight operate at the server: shop.example.com. With today=E2=80=99s = sophistication of=0Ashopping sites, involving user reviews and ratings, use= r-profiling and=0Ajust-in-time ad placements, recommender systems, sophisti= cated searching,=0Aproduct videos, Facebook tie-ins and so much more, the a= ttack surface presented=0Ato malware operators is substantial. In the past,= malware presences on such=0Asites have harvested immense numbers of credit= card credentials to subsequently=0Aperpetrate massive online fraud. So a d= ifferent compartmentalization approach=0Aat the server end might be to divo= rce the card handling transaction from the=0Arest of the shopping site. In = such a configuration, the vendor might set-up a=0Alow-complexity site: buy.= example.com that will process final check-outs=0Aassembled at shop.example.= com. So in this case, upon check-out at=0Ashop.example.com, this server wil= l send out a 308 message specifying a side=0Asession with buy.example.com -= to independently handle the credentials=0Atransaction. This dedicated serv= er should ideally have a much smaller attack=0Asurface, since it only needs= to handle a small subset of the HTTP protocol,=0Anever mind all the sophis= ticated features of modern shopping sites, and just=0Aneeds to communicate = simple transaction parameters with the shopping server =E2=80=93=0Awhich sh= ould allow for more robust security (all without extra NIC=0Afunctionality)= . Such a side channel set-up might also be configured in some way=0Aat the = client end (using Bluetooth or near-field communications) with an=0Aindepen= dent device such as a mobile phone =E2=80=93 if such a device can be truste= d to=0Abe malware-free (a big =E2=80=9Cif=E2=80=9D).=0AAdditional Modes of = Provided Protection:=0AThe above description has described configurations t= hat work=0Awell to keep critical credentials outside the purview of residen= t host malware=0A=E2=80=93 but this isn=E2=80=99t the only type of fraud th= at such configurations can protect=0Aagainst. Consider a malware presence o= n the client device that actually=C2=A0alters the user-agent/browser softwa= re in such a way as to perform=0Aman-in-the-middle tampering with transacti= ons in a way that is hidden from the=0Auser. In this scenario, a user might= think he is making a modest purchase for=0Adelivery to his house, or be ma= king a certain transaction while banking online,=0Abut behind the scenes, t= he malware is making completely different transactions=0Ato the malware ope= rator=E2=80=99s advantage =E2=80=93 such as making a large purchase with=0A= delivery specified to a malware operator=E2=80=99s designated address. With= the=0Aspecification above, whatever the server sees as the issued transact= ion coming=0Aout of the client (possibly fraudulent), is actually reflected= back to the user=0Ain the side session and is intercepted by the compartme= ntalized function for=0Araw presentation to the user (e.g. =E2=80=9CPurchas= e $8192.64 for delivery to Badtown,=0AFraudistan=E2=80=9D), such that the u= ser can truly verify that what he intended has=0Agone through unaltered by = malware. This can also apply to stock purchases,=0Afinancial transfers and = the like during online banking sessions.=0A=E2=80=A6More to come=E2=80=A6= =0AOf course many more details need to be handled. Here are=0Aoutlines of s= ome of them.=0ASide session encryption: The transactions are very short =E2= =80=93=0Awe might just restrict things to UDP and only allow the public key= encryption=0Aand not allow change to options such as RC4 to minimize compa= rtmentalized=0Afunctionality. On the other hand, encryption like RC4 isn=E2= =80=99t very complex; and=0Ashould we want to evolve things to allow the us= er to submit more complex=0Ainformation securely, such as health informatio= n contained on a USB key, then=0Aan RC4 capability would be useful.=0ASmall= side session brute force encryption cracking: Small=0Aencryption payloads = are subject to brute force attacks in general, substantial =E2=80=9Cnonce= =E2=80=9D=0Ainclusions will be required. It will also be helpful to reduce = guessable=0Aplaintext entropy that facilitates cryptographic attacks. So ra= ther than a=0Aserver sending out requested credentials parameters as full t= ext, such as=0A=E2=80=9Center card number=E2=80=9D, =E2=80=9Center expirati= on date=E2=80=9D and the so on, we could predefine many=0Acommon fields, an= d just require the server to list index numbers of these=0Apredefined field= s to be presented to the user in a native language form at the=0Aclient end= . Candidate common fields would be: 1) user ID, 2) password, 3)=0Aaccount I= D, 4) transaction verification code, 5) card holder name, 6) card=0Anumber,= 7) expiration date, 8) card verification code, 9) address line 1, etc.=0AC= ompartmentalized NIC capability: The compartmentalized NIC function=0Awould= need to use/verify DNS look-up info for the side session channel and=0Apre= sent it to the user. The user would need to be sure that malware tampering= =0Awith the browser operation isn=E2=80=99t sending him to a false-front we= b site.=0ACertificate checking and warnings also apply here.=0APassword sub= mission: In some circumstances, it might be=0Aadvantageous to allow hashed = passwords to be submitted by the side channel=0Awithout the complexity of a= higher layer of encryption.=0A=E2=80=A6 and more =E2=80=A6=0A=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AFinally =E2=80=93 = At some point I=E2=80=99d like to have a broader=0Adiscussion on the role f= or pairing up well-defined ports and protocols with dedicated/embedded=0Aha= rdware packet/message handling that cannot be mediated by higher layers of = software.=0ABefore I came involved with internet systems in the late 1990= =E2=80=99s, my job was=0Alargely focused on traditional circuit-switched te= lecom networks. While these=0Anetworks did not have anything near the flexi= bility and power of packet-switched=0Ainternets, the relatively locked down= signalling and routing functions didn=E2=80=99t=0Aenable the widespread mi= suse that has been seen within internets. So I=E2=80=99m wondering=0Aif the= re should not be well-defined protocol ports that trigger embedded=0Ahardwa= re handling of functions that are free from intervention of higher layer (p= ossibly=0Amalicious) software that may be running on a given router/proxy/g= ateway. For a=0Aspecific example, consider a home-gateway =E2=80=93 some of= which have be infected by=0Amalware =E2=80=93 and thus can be reprogrammed= by a malware operator. If some functions=0Aof such a gateway were immutabl= e to higher level control, then even in a=0Apresence of malware, some criti= cal functions could still correctly operate for=0Aconnected PCs. Consider D= NS for example. Suppose a lower layer hardware=0Acapability existed that in= dependently makes a log of a boot protocol connection=0Ato a DSL or cable m= odem network, noting the IP addresses of top level DNS domains.=0AThen imag= ine that when a PC connects to this gateway, that the same hardware=0Acompo= nent supplies these DNS IP addresses to the PCs through a subsequent boot= =0Aprotocol transaction. This means that malware on the gateway would not b= e able=0Ato tamper with this critical information. Now further suppose that= this=0Ahardware capability were responsible for the passing of DNS/port 53= =0Acommunications between each side of the gateway. Again, the happy result= would=0Abe that malware on the gateway would be unable to tamper with thes= e critical=0Asessions.=0AWere we to contemplate such configurations for DNS= ,=0Acertificate authorities and more, we might well achieve the best of tra= ditional=0Atelecom and internet worlds, with broad application flexibility = coupled to a=0Atamper-proof core infrastructure.=0AComments/questions? =C2= =A0 ---851882195-2051486450-1359248283=:95780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A=0AHi Al= l =E2=80=93
=0A=0A
Attached is t= he first outline of the HTTP-Auth submission I=0Apromised last year. There = are still quite a few details that need to be pinned=0Adown, but there is e= nough of a high level specification to shake out any top=0Alevel implementa= tion or compatibility concerns. I have provided some quick=0Aoutlines for s= ome details sections in order to preview needed refinements. Finally,=0Aat = the end I=E2=80=99ve included an open-ended question on how this kind of ap= proach=0Acould add value to other protocols and capabilities within interne= t systems.
=0A=0A
Questions/comments? =
=0A=0A
Thanks in advance for looking a= t this. I=E2=80=99ll be traveling=0Athis coming week with limited access to= email; I=E2=80=99ll be able to handle quick=0Aquestions, but more complex = replies will have to wait until next week.
=0A=0A
Jim McAlear
=0AOttawa, Canada
=0A=0A
Title: <= /o:p>
=0A= =0A
New Security Options for HTTP Authent= ication Handling of=0ACredentials and Critical Transactions
=0A=0A=
Abstract:
=0A=0A
This document defines new options for handling critical=0Acredenti= als and transactions (that involve the use of passwords, credit card=0Anumb= ers and more) within the HTTP protocol in order to open up new approaches= =0Ato providing host-level security at clients and servers. These new forms= of=0Acredentials handling require only minor variations of current HTTP pr= ocessing=0Acapabilities of current client and server software stacks; what = these variants=0Aaccomplish, is to layer and structure the protocol details= in such a way that=0Apermits different forms of compartmentalization or sa= ndboxing to apply within=0Ahosts such that these critical transactions can = be handled outside the reach of=0Aall-to-common host-resident malware. Some= compartmentalization examples are=0Aprovided herein; these are meant to be= suggestive, not prescriptive, and the=0Astructure of the protocol provides= implementers with a large degree of=0Aflexibility to configure suitably co= mpartmentalized or sandboxed solutions at=0Aclients and servers.=
=0A=0A
Introduction:
=0A=0A
<= font size=3D"3">The introduction to the draft HTTP 2.0 protocol=0Aspecifica= tion states: HTTP has been a wildly successful protocol. This is not=0Aonly= true from an engineering perspective, but also from that of end-users. So= =0Ain contemplating improvements to this protocol, it is not only appropria= te to=0Aengineer efficiency gains such as SPDY, but to also examine avenues= to address=0Akey user concerns. So while HTTP has been wildly successful i= n connecting users=0Ato all kinds of desired services, the main shortcoming= perceived by users is suscep= tibility to various forms of fraud and=0Aidentity theft =E2=80=93 especiall= y due to the theft of critical credentials. Of course=0Athis is much more t= han a worry; such crimes are being committed on a massive,=0Aindustrial sca= le and years of countervailing efforts have not successfully stemmed=0Athis= crime wave. The vast majority of these crimes come about due to malware=0A= infections of host computers; it is well beyond the practical ability of=0A= protocol developers to delve into this incredibly complex realm to offer=0A= general solutions against malware exploitation.
=0A=0A
= But an opportunity has arisen to define a solution that ca= n=0Ahandle critical credentials and transactions outside the reach of (pres= umed)=0Ahost=E2=80=93resident malware.&n= bsp; This proposed=0Acontribution will define optional hardware refe= rence configurations for compartmentalized=0Ahandling of key credentials an= d transactions, and then proceed to define=0Aprotocol details that enable s= uch secure handling of this critical information.=0AFor maximum host archit= ecture compartmentalization flexibility, the reference=0Ahardware compartme= ntalization will focus at the point of the host Network=0AInterface Card (o= r Component) =E2=80=93 this being the lowest point within the host=0Aarchit= ecture operating at the physical layer connection to a network. In this=0Aw= ay, if the protocol can support a compartmentalized credentials handling=0A= interdiction at that low point, then other compartmentalized or sandboxed= =0Aoptions are also opened up at higher layers within the host hardware and= =0Asoftware architectures. So the upshot of this proposed contribution is t= hat it=0Aopens up whole new approaches to host security as far as handling = critical=0Acredentials and transactions, though it is up to computer hardwa= re and software=0Adevelopers to fulfill these within their designs.
=0A= =0A
Compartmentalization Reference Hardwa= re Configuration:
=0A=0A
The reference= hardware configuration defined for this new=0Aspecification concerns new f= unctionality of the Network Interface Card (or Component=0A=E2=80=93 either= way abbreviated as NIC) of a host computer. It is assumed here that=0Athis= component has an additional outboard interface, a USB port for the sa= ke=0Aof concreteness, and new independent functionality to monitor, interce= pt and=0Amanipulate very specific credentials communications that take plac= e across the=0Anetwork. This outboard port will be accessible to specific c= ircuitry of the=0ANIC, but not be exposed in any way to the higher layers o= f host hardware nor=0Athe operating system. At the client end of the commun= ication, the USB port will=0Atypically attach to a keyboard in a way that t= he user can enter credentials almost=0Adirectly into the transaction protoc= ol without keystrokes going to the host=0Aoperating system (and through any= malware enabled keystroke-capture capability).=0AMore elaborately, the key= board would have an embedded display that operates=0Aindependently of the o= perating system, such that the user can view the proposed=0Atransaction/cre= dentials request details and compose a suitable reply if the=0Arequest deta= ils are satisfactory =E2=80=93 just barely off the connection from the=0Aph= ysical layer. This function would be triggered as the result of a=0Awell-de= fined protocol condition observed in the NIC. When this operation is=0Atrig= gered, the connected keyboard component will be blocked from sending=0Akeys= trokes via the conventional connection to the operating system, until the= =0Acredentials transaction has completed or cancelled. At the server end, t= he USB=0Aport of the NIC would connect to a USB memory/processor stick cont= aining a=0Adatabase of user passwords or credit card merchant account infor= mation, such=0Athat credentials transactions can likewise be completed outs= ide the purview of=0Athe host operating system and thus any resident malwar= e. The next section will=0Acover the essentials of operation with these con= figurations =E2=80=93 though an example=0Awill also be provided where the c= ompartmentalization doesn=E2=80=99t need to be applied=0Aat the NIC level = =E2=80=93 thus demonstrating the flexibility for host software and=0Ahardwa= re architects to innovate in the area of compartmentalizing or sandboxing= =0Acredentials transactions away from presumed resident malware. And though= this=0Areference configuration makes mention of a physical keyboards, disp= lays and=0ANICs and outboard ports, these are by no means prescriptive =E2= =80=93 useful=0Aalternatives to these are exposed within a referenced publi= cation [tbd].
=0A=0A
Key Protocol Featu= res for Operation with Reference=0AConfigurations:=
=0A=0A
Here we begin with a situation where an existing HTTP or= =0AHTTPS connection has already been initiated, and the server software rea= ches a=0Acondition whereby it needs a credentials submission by a user =E2= =80=93 be it the=0Asubmission of a password, or a set of credit card parame= ters, or other=0Asensitive information like a passport number or a Social S= ecurity Number. For=0Athe most restrictive case, we will assume here that t= he existing connection is=0AHTTPS. At this point we will require the server= to send the client a (proposed)=0AHTTP 308 Message: Request Credentials Si= de Session. Within the body of this 308=0Aresponse will be a specification = of the intended host (e.g. buy.example.com)=0Aand a one-time transaction id= entifier (a pseudo-random alphanumeric string) to=0Aassociate a to-be-creat= ed side session with the original session at the server=0Aend (important fo= r making session associations passing through proxy servers).=0AAt this poi= nt the user-agent of at the client will send out a first message to=0Aa wel= l-defined (proposed) server port 446 as if a new HTTPS session were to be= =0Acreated (this may be done over a new TCP session or a UDP interchange). = The=0Alead message will have the specified host and transaction identifier = fields=0Aincluded in the clear.  The added NIC=0Abased functionality in the client reference configurat= ion would monitor incoming=0Aand outgoing packets to server port 446 and th= en proceed to intercede and take=0Aover the side session until completion (= or cancellation). Thus the client NIC=0Awould then interact with the server= to set up a TLS session, using its own=0Aindependent encryption capabiliti= es, and once established the server would=0Aprovide a specification of an i= ntended transaction and desired user credentials =E2=80=93=0Asuch that the = compartmentalized functionality of the NIC will then present and=0Acollect = these from the user for secure submission to the server. All the while=0Ath= is is happening, the compartmentalized NIC functionality will block any=0Ap= ackets to and from server port 446 from ever reaching any other components = of=0Athe host system. It must be noted that this side session must not invo= lve the=0Afull set of HTTP capabilities, but just a very limited interactio= n to allow=0Acredentials transactions. The server cannot know if the client= NIC incorporates=0Athis functionality, for that matter the client user-age= nt may not have this=0Aknowledge in advance. Thus if the client NIC does no= t have this functionality,=0Aor if an enabled NIC notes that a keyboard cap= ability has not been connected to=0Athe outboard port, then these 446 messa= ges are passed to the operating system=0Aand user-agent must complete the t= ransaction per the details of this=0Aspecification (in the current fashion = that risks malware access).
=0A=0A
A = complementary process can occur at the server end. If the=0Aserver NIC has = the needed compartmentalized functions that are triggered on=0Aport 446 act= ivity, then this capability is triggered to respond to the client=0Arequest= ed side session set-up using its own encryption capabilities and=0Ablocking= port 446 messages from reaching the upper hardware and software layers=0Ao= f the server host. The key exception is that once the compartmentalized NIC= =0Acapability has taken over the session, it will send a message up to the = higher=0Alayers of the server using port 446 and containing the intended ho= st and=0Asession number (in a different form than what the client side has = sent), to=0Areceive from the higher layers of the server the required param= eters of the=0Atransaction. For a credit card transaction, these parameters= would normally=0Ainclude the purchase details of: amount to charge and shi= pping address (if=0Aneeded), and then a specification for credit card param= eters requested =E2=80=93 such=0Aas card number, expiry date and verificati= on code. Such information would be=0Asent by the higher layers of the serve= r down to port 446 and be intercepted by=0Athe NIC functionality. The NIC w= ould then encapsulate such parameters within=0Athe encrypted session with t= he client side and await the user response. Upon=0Areceipt of the user cred= entials from the client end, the NIC and USB key=0Afunctionality could then= independently contact a credit card clearance service=0Ato validate the tr= ansaction. The transaction success/fail response and summary=0Acode would t= hen be passed up to the server on port 446. The details of the=0Atransactio= n would normally be logged within the attached USB key for an=0Aindependent= record that is inaccessible by any server-resident malware. In an=0Aaltern= ative interaction, the USB memory stick could contain a database of=0Apassw= ord information, and could verify password submissions without malware=0Aha= ving any access to the password database. Other alternatives are described = in=0Aa reference publication [tbd].
=0A=0A
As discussed earlier, while the protocol definition enables=0Acompartme= ntalization that can operate just above the physical connection to the=0Ane= twork, other options are still viable. In terms of host security - complexi= ty=0Ais the enemy of security. So consider a high volume online storefront = that=0Amight operate at the server: shop.example.com. With today=E2=80=99s = sophistication of=0Ashopping sites, involving user reviews and ratings, use= r-profiling and=0Ajust-in-time ad placements, recommender systems, sophisti= cated searching,=0Aproduct videos, Facebook tie-ins and so much more, the a= ttack surface presented=0Ato malware operators is substantial. In the past,= malware presences on such=0Asites have harvested immense numbers of credit= card credentials to subsequently=0Aperpetrate massive online fraud. So a d= ifferent compartmentalization approach=0Aat the server end might be to divo= rce the card handling transaction from the=0Arest of the shopping site. In = such a configuration, the vendor might set-up a=0Alow-complexity site: buy.= example.com that will process final check-outs=0Aassembled at shop.example.= com. So in this case, upon check-out at=0Ashop.example.com, this server wil= l send out a 308 message specifying a side=0Asession with buy.example.com -= to independently handle the credentials=0Atransaction. This dedicated serv= er should ideally have a much smaller attack=0Asurface, since it only needs= to handle a small subset of the HTTP protocol,=0Anever mind all the sophis= ticated features of modern shopping sites, and just=0Aneeds to communicate = simple transaction parameters with the shopping server =E2=80=93=0Awhich sh= ould allow for more robust security (all without extra NIC=0Afunctionality)= . Such a side channel set-up might also be configured in some way=0Aat the = client end (using Bluetooth or near-field communications) with an=0Aindepen= dent device such as a mobile phone =E2=80=93 if such a device can be truste= d to=0Abe malware-free (a big =E2=80=9Cif=E2=80=9D).
=0A=0A
<= div style=3D"margin: 0cm 0cm 10pt;" class=3D"MsoNormal">Additional Modes of Provided Protection:
=0A=0A
The above description has described configura= tions that work=0Awell to keep critical credentials outside the purview of = resident host malware=0A=E2=80=93 but this isn=E2=80=99t the only type of f= raud that such configurations can protect=0Aagainst. Consider a malware pre= sence on the client device that actually alters the user-agent/browser= software in such a way as to perform=0Aman-in-the-middle tampering with tr= ansactions in a way that is hidden from the=0Auser. In this scenario, a use= r might think he is making a modest purchase for=0Adelivery to his house, o= r be making a certain transaction while banking online,=0Abut behind the sc= enes, the malware is making completely different transactions=0Ato the malw= are operator=E2=80=99s advantage =E2=80=93 such as making a large purchase = with=0Adelivery specified to a malware operator=E2=80=99s designated addres= s. With the=0Aspecification above, whatever the server sees as the issued t= ransaction coming=0Aout of the client (possibly fraudulent), is actually re= flected back to the user=0Ain the side session and is intercepted by the co= mpartmentalized function for=0Araw presentation to the user (e.g. =E2=80=9C= Purchase $8192.64 for delivery to Badtown,=0AFraudistan=E2=80=9D), such tha= t the user can truly verify that what he intended has=0Agone through unalte= red by malware. This can also apply to stock purchases,=0Afinancial transfe= rs and the like during online banking sessions.
=0A=0A
=E2=80=A6More to come=E2=80=A6
=0A=0A
Of course many more details need to be handled. Here are=0Ao= utlines of some of them.
=0A=0A
Side se= ssion encryption: The transactions are very short =E2=80=93=0Awe might just= restrict things to UDP and only allow the public key encryption=0Aand not = allow change to options such as RC4 to minimize compartmentalized=0Afunctio= nality. On the other hand, encryption like RC4 isn=E2=80=99t very complex; = and=0Ashould we want to evolve things to allow the user to submit more comp= lex=0Ainformation securely, such as health information contained on a USB k= ey, then=0Aan RC4 capability would be useful.
=0A=0A
Small side session brute force encryption cracking: Small=0Ae= ncryption payloads are subject to brute force attacks in general, substanti= al =E2=80=9Cnonce=E2=80=9D=0Ainclusions will be required. It will also be h= elpful to reduce guessable=0Aplaintext entropy that facilitates cryptograph= ic attacks. So rather than a=0Aserver sending out requested credentials par= ameters as full text, such as=0A=E2=80=9Center card number=E2=80=9D, =E2=80= =9Center expiration date=E2=80=9D and the so on, we could predefine many=0A= common fields, and just require the server to list index numbers of these= =0Apredefined fields to be presented to the user in a native language form = at the=0Aclient end. Candidate common fields would be: 1) user ID, 2) passw= ord, 3)=0Aaccount ID, 4) transaction verification code, 5) card holder name= , 6) card=0Anumber, 7) expiration date, 8) card verification code, 9) addre= ss line 1, etc.
=0A=0A
Compartmentalize= d NIC capability: The compartmentalized NIC function=0Awould need to use/ve= rify DNS look-up info for the side session channel and=0Apresent it to the = user. The user would need to be sure that malware tampering=0Awith the brow= ser operation isn=E2=80=99t sending him to a false-front web site.=0ACertif= icate checking and warnings also apply here.
=
=0A=0A
Password submission: In some circumstances, it might be=0Aadva= ntageous to allow hashed passwords to be submitted by the side channel=0Awi= thout the complexity of a higher layer of encryption.
=0A=0A
=
<= font face=3D"Calibri">=E2=80=A6 and more =E2=80=A6=
=0A=0A
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=0A=0A
Finally =E2=80=93 A= t some point I=E2=80=99d like to have a broader=0Adiscussion on the role fo= r pairing up well-defined ports and protocols with dedicated/embedded=0Ahar= dware packet/message handling that cannot be mediated by higher layers of s= oftware.=0ABefore I came involved with internet systems in the late 1990=E2= =80=99s, my job was=0Alargely focused on traditional circuit-switched telec= om networks. While these=0Anetworks did not have anything near the flexibil= ity and power of packet-switched=0Ainternets, the relatively locked down si= gnalling and routing functions didn=E2=80=99t=0Aenable the widespread misus= e that has been seen within internets. So I=E2=80=99m wondering=0Aif there = should not be well-defined protocol ports that trigger embedded=0Ahardware = handling of functions that are free from intervention of higher layer (poss= ibly=0Amalicious) software that may be running on a given router/proxy/gate= way. For a=0Aspecific example, consider a home-gateway =E2=80=93 some of wh= ich have be infected by=0Amalware =E2=80=93 and thus can be reprogrammed by= a malware operator. If some functions=0Aof such a gateway were immutable t= o higher level control, then even in a=0Apresence of malware, some critical= functions could still correctly operate for=0Aconnected PCs. Consider DNS = for example. Suppose a lower layer hardware=0Acapability existed that indep= endently makes a log of a boot protocol connection=0Ato a DSL or cable mode= m network, noting the IP addresses of top level DNS domains.=0AThen imagine= that when a PC connects to this gateway, that the same hardware=0Acomponen= t supplies these DNS IP addresses to the PCs through a subsequent boot=0Apr= otocol transaction. This means that malware on the gateway would not be abl= e=0Ato tamper with this critical information. Now further suppose that this= =0Ahardware capability were responsible for the passing of DNS/port 53=0Aco= mmunications between each side of the gateway. Again, the happy result woul= d=0Abe that malware on the gateway would be unable to tamper with these cri= tical=0Asessions.
=0A=0A
Were we to co= ntemplate such configurations for DNS,=0Acertificate authorities and more, = we might well achieve the best of traditional=0Atelecom and internet worlds= , with broad application flexibility coupled to a=0Atamper-proof core infra= structure.
=0A=0A
Comments/questions? =  
=0A=0A
---851882195-2051486450-1359248283=:95780-- From turners@ieca.com Mon Jan 28 06:24:40 2013 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 DE7EE21F8889 for ; Mon, 28 Jan 2013 06:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 HVoh3JoVLbds for ; Mon, 28 Jan 2013 06:24:40 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.195.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECE821F8871 for ; Mon, 28 Jan 2013 06:24:40 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 228F941537FC4; Mon, 28 Jan 2013 08:24:40 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 1711041537F8E for ; Mon, 28 Jan 2013 08:24:40 -0600 (CST) Received: from [108.45.19.185] (port=61486 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TzpdX-0005b0-SU for http-auth@ietf.org; Mon, 28 Jan 2013 08:24:39 -0600 Message-ID: <51068A27.1050601@ieca.com> Date: Mon, 28 Jan 2013 09:24:39 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <50F2F075.8090809@cs.tcd.ie> In-Reply-To: <50F2F075.8090809@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:61486 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [http-auth] charter rev -03 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, 28 Jan 2013 14:24:41 -0000 Right so the plan here is to put this on the BOF list with the hope that a WG will get formed before IETF 86. Obviously this plan is predicated on more expressions of support for the proposed charter. spt On 1/13/13 12:35 PM, Stephen Farrell wrote: > > Hi all and happy new year, > > Sorry to have done nothing since mid-Nov on this, but I've > finally gotten around to going back over the list traffic > and modified the text to make the attached -03 version of > the charter. > > I think this one is good enough to hand over to Sean to see > what he wants to do about it, that is, I don't see it getting > way way better due to mail on this list, so I reckon we're > done for now, and its over to Sean to see what he thinks. > > Cheers, > S. > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From stephen.farrell@cs.tcd.ie Mon Jan 28 07:18:03 2013 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 9E6CD21F841D for ; Mon, 28 Jan 2013 07:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gBW3Rknfunnc for ; Mon, 28 Jan 2013 07:18:03 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9021F8168 for ; Mon, 28 Jan 2013 07:18:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E49DBDC7; Mon, 28 Jan 2013 15:17:41 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is5UCwyN1hLG; Mon, 28 Jan 2013 15:17:37 +0000 (GMT) Received: from [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e] (unknown [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 450A7BE20; Mon, 28 Jan 2013 15:17:37 +0000 (GMT) Message-ID: <51069692.20706@cs.tcd.ie> Date: Mon, 28 Jan 2013 15:17:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sean Turner References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> In-Reply-To: <51068A27.1050601@ieca.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 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, 28 Jan 2013 15:18:04 -0000 On 01/28/2013 02:24 PM, Sean Turner wrote: > Right so the plan here is to put this on the BOF list with the hope that > a WG will get formed before IETF 86. Obviously this plan is predicated > on more expressions of support for the proposed charter. As a draft author, I think forming a wg with this charter would be good. (As an IESG member, I'll be recusing myself from IESG balloting on this.) S.