From bkihara.l@gmail.com Wed Oct 3 22:26:59 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 1AE4921F8599 for ; Wed, 3 Oct 2012 22:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 h0RfMnOZBOTj for ; Wed, 3 Oct 2012 22:26:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C621F8596 for ; Wed, 3 Oct 2012 22:26:58 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so131927vcb.31 for ; Wed, 03 Oct 2012 22:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jZLaoUT+XGoiEBvAPOx+rXm5Qp1Jc+6BS2MpaBYE5Kg=; b=bj1MWgVtV7tGCKVis5aQdtO7PQt5aYe4WR1v5RlgTqpve/fYUCHmTXYo4julVLuH17 vqcf7FQILNU8I95A9ZJeLKU+2HQex3T2RKMNZBl/wLIjTUwleaaTURlqUcuZJoFGI+5B x7KwsaqXOj7NPah1cFuOkJkE0Vo3zMtH1mmDive6QN/xwl7SChVzNVbW+lzlLd9SCl3C Tv8pMfqoD6Y89hHfEfZ/by32mcI0Cddw+6R/3aH9RcwWycFEiTxhEukQBaToCIWUoObf MgJl1VDUKKy+af6XCpwtqWA9MyAFLA3ObU0hz9quOAZVIxJK3T1Yq435HLtJ4FAejbL/ K+fA== MIME-Version: 1.0 Received: by 10.52.22.72 with SMTP id b8mr2003333vdf.88.1349328417790; Wed, 03 Oct 2012 22:26:57 -0700 (PDT) Received: by 10.58.221.33 with HTTP; Wed, 3 Oct 2012 22:26:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Oct 2012 14:26:57 +0900 Message-ID: From: "KIHARA, Boku" To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Cc: http-auth@ietf.org Subject: Re: [http-auth] CRIME to Basic or Bearer Tokens 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, 04 Oct 2012 05:26:59 -0000 2012/9/27 Tom Ritter : > On 27 September 2012 06:26, KIHARA, Boku wrote: >> When I read summaries of the CRIME for TLS, I suspect that this attack >> can be applied to HTTP Basic authentication and other bearer-token-type >> authentication schemes because browsers send the Authorization header >> field automatically. Is my thought right? > > Yes. Thank you. I have experimented briefly on CRIME attack to Basic and succeeded to steal the password of the experiment environment. Regards, Boku Kihara From ynir@checkpoint.com Fri Oct 5 09:23:59 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 7FB1521F85B1 for ; Fri, 5 Oct 2012 09:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 AmST4Z+EvA+F for ; Fri, 5 Oct 2012 09:23:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8139721F8585 for ; Fri, 5 Oct 2012 09:23:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q95GNuix009369 for ; Fri, 5 Oct 2012 18:23:56 +0200 X-CheckPoint: {506F085F-6-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Oct 2012 18:23:55 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 5 Oct 2012 18:23:55 +0200 From: Yoav Nir To: "http-auth@ietf.org" Date: Fri, 5 Oct 2012 18:23:55 +0200 Thread-Topic: BoF in Atlanta Thread-Index: Ac2jFdBVJFyIXs1fRkqBU3ebORxHxg== Message-ID: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [http-auth] BoF in Atlanta 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: Fri, 05 Oct 2012 16:23:59 -0000 Hi all The preliminary agenda is now posted at https://datatracker.ietf.org/meetin= g/85/agenda.txt , as well as at http://tools.ietf.org/agenda/85/ Either way, we are currently scheduled to meet at 13:00 on Wednesday, 7-Nov= , in Grand Ballroom D. We have 1.5 hours to go. Note that we cannot guarant= ee that the scheduling will not change, but it is not likely to, and we'll = do our best to keep it on Wednesday. We propose the following agenda: - 13:00-13:05 Blue sheets, Note Well and agenda bashing - 13:05-13:20 Introduction and problem statement - 13:20-14:00 (Short!!!) presentations on the candidates - 14:00-14:30 Charter hack, and the usual BoF questions People with candidate documents, who wish to present at the session should = do the following: - Notify the chairs sooner rather than later - Prepare a short presentation.=20 * You will only have a few minutes each and want to leave time for Q&A, s= o plan on no more than 5 minutes of presso. * You don't each need to explain the problem. We'll do it in the introduc= tion. * You don't each need to explain what is the "HTTP authentication framewo= rk". - Send slides to the chairs (PDF or PPT format) early - no later than Monda= y the 5th. - If you would like to present, but will not be at the meeting, please cont= act us early so that we can arrange remote presentation or presentation by = proxy. See you all there Derek & Yoav From paul.hoffman@vpnc.org Fri Oct 5 15:09:12 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 0D02321F862B for ; Fri, 5 Oct 2012 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 SPOCAo1QA7Lu for ; Fri, 5 Oct 2012 15:09:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 70A7021F8629 for ; Fri, 5 Oct 2012 15:09:11 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q95M99ic007065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Oct 2012 15:09:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 15:09:09 -0700 References: <20121005213834.7474.81684.idtracker@ietfa.amsl.com> To: http-auth@ietf.org Message-Id: <75E2A65D-874F-4EAD-8DAB-CD0030EC5EAE@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [http-auth] A more complete HOBA draft 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: Fri, 05 Oct 2012 22:09:12 -0000 Greetings again. Stephen and Michael and I wanted to get this to the = list early so that discussion might be incorporated into a -03 before = the cutoff. Note that this is still a very rough proposal. As we say in the draft, = we want to have just one set of mechanisms that can be used both for the = HTTP authentication and the JavaScript authentication; we'll see how = close we can get to each other. The high-order bits are: get rid of passwords, and make this a drop-in = replacement for current password use on web sites. --Paul Hoffman Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-farrell-httpbis-hoba-02.txt > Date: October 5, 2012 2:38:34 PM PDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : HTTP Origin-Bound Authentication (HOBA) > Author(s) : Stephen Farrell > Paul Hoffman > Michael Thomas > Filename : draft-farrell-httpbis-hoba-02.txt > Pages : 20 > Date : 2012-10-05 >=20 > Abstract: > HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP > authentication method with credentials that are not vulnerable to > phishing attacks, and that does not require a server-side password > database. The design can also be used in Javascript-based > authentication embedded in HTML. HOBA is an alternative to HTTP > authentication schemes that require passwords with all the negative > attributes that come with password-based systems. HOBA can be > integrated with account management and other applications running > over HTTP and supports portability, so a user can associate more = than > one device or origin-bound key with the same service. We also > describe a way in which the HOBA design can be used from a = Javascript > web client. When deployed, HOBA will be a drop-in replacement for > password-based HTTP authentication or JavaScript authentication. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrell-httpbis-hoba >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02 From henry.story@bblfish.net Tue Oct 9 00:47:30 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 283B421F876D for ; Tue, 9 Oct 2012 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Xr+uCW22wOiu for ; Tue, 9 Oct 2012 00:47:27 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92521F8674 for ; Tue, 9 Oct 2012 00:47:26 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so3689778wib.13 for ; Tue, 09 Oct 2012 00:47:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version:x-mailer :x-gm-message-state; bh=TNqpK4k4RQIkmxDJI8wDpVM7K4SFB5jvZfp1iHmg5e4=; b=eOY6B0L3K9dL0A7UWl3yFcfplFLa2dPiJbGdFYBWsIc4IK7bpN7Lz+kGLQWkt3yMQb zKSBUDt6Q7bWtef4zE5H8I9KmS8oe5Wa3VszVxdAHL1nW/LN+YpotG3URSbiV0plZbhn eRUk4EDH8g++wvy7IvsRRvIFAeur2lFMlcLqZ26lcgqr+bdVGg7Ws3EakOEuLuUWKyko dpZPzYPbkCiQtc32M1xiiFXo+Zy+iZBPKzHHEthAtfEYDUd0vqznGeUO89mJY7RG8eU/ oz++FuezjtBdNiu+8MofjG/m5Rs0//sytVK2tjl9SvCr41AMvJjvvA260pmvaE5Kv4Vk +8Lw== Received: by 10.216.28.140 with SMTP id g12mr12060620wea.59.1349768845848; Tue, 09 Oct 2012 00:47:25 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-329-35.w83-114.abo.wanadoo.fr. [83.114.96.35]) by mx.google.com with ESMTPS id b7sm23703748wiz.3.2012.10.09.00.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 00:47:24 -0700 (PDT) From: Henry Story Content-Type: multipart/signed; boundary="Apple-Mail=_E23EF9D3-9FC9-4035-A711-B4D790E012C1"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Date: Tue, 9 Oct 2012 09:47:22 +0200 To: Yoav Nir , "http-auth@ietf.org" , Derek Atkins Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnTgOTNrfuJ6HSYFaUhB5Z0eyXCNGKk1+jdupuR1C7P4xR1zwgwiZQ9nQdcDITyLVwlgD0u Subject: [http-auth] TLS authentication remarks 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: Tue, 09 Oct 2012 07:47:30 -0000 --Apple-Mail=_E23EF9D3-9FC9-4035-A711-B4D790E012C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On the TLS mailing list, a discussion on making TLS = Client-Authentication useful was ruled=20 out of bounds, and Yoav Nir suggested this be a better place to argue = for it. Since I=20 have been discussing this quite widely I just wanted to collect the = discussions I have=20 had in various groups on the w3c and ietf here, to help perhaps provide = material for=20 your Atlanta BOF ( which I won't be attending, though I will be at W3C = TPAC [2] ) So to start off with my argument for TLS authentication comes from = experience we have had developing the WebID protocol at the W3C, which is just = really=20 explaining how one can use TLS to do client authentication globally and = usefully. At this point some people's hair stand on end, because this implies = linkability of identity across sites. So I recently posted an argument for "Liking = Linkability" on the saag@ietf.org and public-privacy@w3.org mailing lists. In short linkability of identity is very important to increase privacy on the = web. http://www.ietf.org/mail-archive/web/saag/current/msg04044.html http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/ So having established that, it is important to notice that TLS can do a = lot more than people realise with client certificates. Essentially with TLS you = can - authenticate on any site using WebID enabled certificates - place information in access controlled manner at the WebID profile = location - use this to create distributed social networks - the social web - use information on the web to improve browser experience More on video at http://webid.info/ and the w3c draft spec = http://webid.info/spec/,=20 and of course a lot of real working code, of which one of the best = currently is https://my-profile.eu/ where you can create a certificate to = authenticate say on https://foafssl.org/srv/idp?rs=3Dhttp%3A%2F%2Fbblfish.net%2F ( but = we need more demo apps - something I am working on ) So the main problem in my view is not at the TLS layer, or at the HTTP = layer but at the browser UI layer. Since I already had a long discussion with = Ben Laurie on the topic I'll just point to it here. Starting from a simple definition of transparency of identity, we = agree that anonymous should be the default on the web, and in my view one is then = committed to making it easy for the user of the browser to see what his identity = is at all times. = http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-= definitions-1Oct.pdf Even Chrome's new persona feature does not give me this transparency of = traceability/identity. I finally show how browsers could use the information available at the = WebID to personalise the UI=20 of the certificate selection box in a non privacy invading manner. = http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-= definition-final.pdf So I think that covers most of my thoughts on the subject. I opened bug = reports elsewhere. Having Used TLS client authentication ( for non = anonymous login of course ) I am pretty impressed by the power of that = technology. IT has been underused in part because =20 - web servers have done a bad job making it easy ( but that is going to = change pretty soon - when servers like Play 2.1 show how one can use = Futures to get certificates in the middle of an http connection, without = breaking state=20 = https://github.com/jroper/Play20/blob/ssl/framework/src/play/src/main/scal= a/play/api/mvc/Http.scala#L57 But we do have otherwise implementations of WebID in every language and = platform=20 ( see http://www.w3.org/wiki/Foaf%2Bssl#Libraries ) - because CA's create a not very believable security method - but = IETF Dane should take care of that=20 So fundamentally: - make UIs transparent please, this may be a legal requirement in = the EU, and even if it is not, browser vendors should do what is right. = See Dr Ian Walden's short contribution=20 http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html - Implement Dane http://tools.ietf.org/html/rfc6698 - play with WebID And you'll find there is a huge amount of fun and great apps that can = appear. Ah and finally TLS versus JS in the browser Crypto. I think in the = browser crypto is going to be a good thing, but not because of Auth - that will be better left = to the TLS layer because: - TLS is efficient=20 - JS is a Turing complete langauge - which download something that big = when a little langauge can do it right - whatever JS brings in advantage on UI level would be better done = declaratively by tying TLS to resources on the web. - JS will only be better if it is not physhable, and the work to do = that right will be just as difficult if not much more than the small improvements to TLS Thats all folks, I need to get back to programming. Hope that helps for the IETF = meeting.=20 All the best from France, Henry =20 [1] http://www.ietf.org/mail-archive/web/tls/current/msg09001.html [2] http://www.w3.org/2012/10/TPAC/ Social Web Architect http://bblfish.net/ --Apple-Mail=_E23EF9D3-9FC9-4035-A711-B4D790E012C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwTQYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDgyOTAxNDU1NloXDTEzMDgzMDA5MjM0MFowZTEZMBcGA1UEDRMQazQ2eDlvOXJDRE5m VzMwYzEgMB4GA1UEAwwXaGVucnkuc3RvcnlAYmJsZmlzaC5uZXQxJjAkBgkqhkiG9w0BCQEWF2hl bnJ5LnN0b3J5QGJibGZpc2gubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArHXp EmiifOSpudkJn1vAnFdZsuaLuYYLbdWL47o1rKD/kg8/RJUmTIM2ara4e/MOxR16mu2fyAca3H1U oIXNNXDbYQDu2PkfLoNSM5JGAoYbfB0nXBK//ZecidVMZ8eExd02/vFzo5vj9kQNaAPSYirid5xe 1cV9Y1RFjlEozuYAUhU8zi3taf22JM45ii2YrCEgVjDdez8yio0QoJeKEEL3JhL4tqpkbfIOHmdi HYx00S6YcCogDfxXc3zOJ3jcIj/F61eXG1qWX/lq9RAyoBjYHLWE2iHQPwdzum03ubcvOTlohqOR +/cVzvx10l6bJ46KitfbydXMh8HoY7QcmwIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQRbT9qwRblII9x nAN2FlEMUD1LQzAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdo ZW5yeS5zdG9yeUBiYmxmaXNoLm5ldDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALj/A19bRLmI7sMf0lVRrdN23NuRC7/UFSLZ DfcxrR1wOtQgAbrFlFLY+Otn6UWYIiWQpv2v5Ploqw9rMam5W8seC3TUt83StohXCmZ0EDmK87If B6kpd7FwJ0RFGCxn22hPU2kuhp2mbjJzCTrd3jWsXw63MXDUzHuucWGX2mY1Ji+zRECh568N7iWA 5jn9kWT+h7o7ywKbHc4qAnksghLYAnTfoCx1IPkT4/8A5hf38imhf9NcNGibrvt/e49sacf6GjRH Ot/lOCrEX2fh2YvTB5sdEKM5tjKCKNpFSqnRCKhsWZ9N9ZP7mRZfCOBjAMsm3CW2ygwlWXc54lgf p1UwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgME0GMwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA5MDc0NzIyWjAjBgkqhkiG9w0BCQQxFgQUt3Ufdcny N4pRWEo9Y/eOSZtMwSIwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgME0GMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwTQYzANBgkqhkiG9w0BAQEFAASCAQACpMy7Tj28DZzPY2Y3LRxYDJy2Z/TkJA6ixJTj JRQXtwgHbQnulYBuutYUsf2U+4f97PEbd/B7+ffNTITKsKJt7CbdWYpD4kQuCS5ssr4HwyarO8YW Z1cdezRoLibyc4yOapRox7o+dkCmeGEZ/1oOzt84GOiT8guxEUQ05vZkxq6CDYkAw+qEPzLZyGLh lAdtZLIKAvsWnofA9Dw8xagpd6CG6uklW6T90rG5U2GQX2Eyi6AP5DMmiYbERnzEW7SNjBc3wjhq RH4DM2CD95/RUHeelVSM1rvLdAQljqtyH5e0KvACK4hpaDiaSvDCr3Ovbzd5en0pbI1kI4fh6ilz AAAAAAAA --Apple-Mail=_E23EF9D3-9FC9-4035-A711-B4D790E012C1-- From llynch@civil-tongue.net Fri Oct 12 11:07:26 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 F21A521F8742 for ; Fri, 12 Oct 2012 11:07:25 -0700 (PDT) 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 odXkwmq9cogI for ; Fri, 12 Oct 2012 11:07:25 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 6B45621F852E for ; Fri, 12 Oct 2012 11:07:25 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id q9CI7CIk074398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Oct 2012 11:07:12 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id q9CI7Bkc074392; Fri, 12 Oct 2012 11:07:11 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Fri, 12 Oct 2012 11:07:11 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Yoav Nir In-Reply-To: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> Message-ID: References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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: Fri, 12 Oct 2012 18:07:26 -0000 On Fri, 5 Oct 2012, Yoav Nir wrote: > Hi all > > The preliminary agenda is now posted at https://datatracker.ietf.org/meeting/85/agenda.txt , as well as at http://tools.ietf.org/agenda/85/ > > Either way, we are currently scheduled to meet at 13:00 on Wednesday, 7-Nov, in Grand Ballroom D. We have 1.5 hours to go. Note that we cannot guarantee that the scheduling will not change, but it is not likely to, and we'll do our best to keep it on Wednesday. > > We propose the following agenda: > - 13:00-13:05 Blue sheets, Note Well and agenda bashing > - 13:05-13:20 Introduction and problem statement > - 13:20-14:00 (Short!!!) presentations on the candidates > - 14:00-14:30 Charter hack, and the usual BoF questions > > People with candidate documents, who wish to present at the session > should do the following: just as an aide mémoire the following documents have been mentioned on the BOF thread: - draft-oiwa-* - draft-farrell-httpbis-hoba - draft-melnikov-httpbis-scram-auth - draft-williams-httpbis-auth-classification - draft-ahrens-httpbis-digest-auth-update (sean) - Note: Actually, please include draft-williams-http-rest-auth (RESTauth, successor to REST-GSS) and remove draft-williams-httpbis-auth-classification. (nico) - What about Negotiate? Its already an informational RFC but I have a hunch that work has been done on it since it was published. Somebody should ask (nudge-nudge) MSFT... (leif) - http://www.w3.org/2012/webcrypto/WebCryptoAPI/ (harry) - There is a proposal in HTML5 for enhancing form support of HTTP which includes 'mapping' username\passwords into the same XHR.open() functionality. Also included is a method for clearing the auth cache on successful response which integrates with a HTTP request for server notification and cookie clearing: http://www.w3.org/wiki/User:Cjones/ISSUE-195 (cameron) Also - - active discussion on I18n but no documents listed - Lucy > - Notify the chairs sooner rather than later > - Prepare a short presentation. > * You will only have a few minutes each and want to leave time for Q&A, so plan on no more than 5 minutes of presso. > * You don't each need to explain the problem. We'll do it in the introduction. > * You don't each need to explain what is the "HTTP authentication framework". > - Send slides to the chairs (PDF or PPT format) early - no later than Monday the 5th. > - If you would like to present, but will not be at the meeting, please contact us early so that we can arrange remote presentation or presentation by proxy. > > See you all there > > Derek & Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From Gabriel.Montenegro@microsoft.com Fri Oct 12 16:09:18 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 D7BBC21F857E for ; Fri, 12 Oct 2012 16:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 0675rsgklgbX for ; Fri, 12 Oct 2012 16:09:18 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 50E2B21F857D for ; Fri, 12 Oct 2012 16:09:18 -0700 (PDT) Received: from BL2FFO11FD014.protection.gbl (10.173.161.201) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 23:10:18 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 12 Oct 2012 23:10:18 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 12 Oct 2012 23:08:55 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.147]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 16:08:55 -0700 From: Gabriel Montenegro To: Lucy Lynch , Yoav Nir Thread-Topic: [http-auth] BoF in Atlanta Thread-Index: Ac2jFdBVJFyIXs1fRkqBU3ebORxHxgFyUJ2AAARUKTA= Date: Fri, 12 Oct 2012 23:08:54 +0000 Message-ID: References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(5343655001)(33656001)(46102001)(42186003)(5343635001)(47776002)(51856001)(31966008)(74502001)(15202345001)(16406001)(47446002)(44976002)(74662001)(50466001)(16826001)(49866001)(1076001)(50986001)(8716001)(47736001)(47976001)(48376001)(4396001)(16696001)(3846001)(4196001)(20776001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0632519F33 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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: Fri, 12 Oct 2012 23:09:18 -0000 SGkgTHVjeSwNCg0KDQo+IGp1c3QgYXMgYW4gYWlkZSBtw6ltb2lyZSB0aGUgZm9sbG93aW5nIGRv Y3VtZW50cyBoYXZlIGJlZW4gbWVudGlvbmVkIG9uDQo+IHRoZSBCT0YgdGhyZWFkOg0KDQpZb3Vy IGxpc3Qgd2FzIG5vdCBjb21wbGV0ZS4gVGhpcyBsaXN0IGhhcyB0aGVtIGFsbDoNCmh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2h0dHBiaXMvdHJhYy93aWtpL0h0dHBBdXRoUHJvcG9zYWxz DQoNCj4gLSBXaGF0IGFib3V0IE5lZ290aWF0ZT8gSXRzIGFscmVhZHkgYW4gaW5mb3JtYXRpb25h bCBSRkMgYnV0IEkgaGF2ZSBhIGh1bmNoDQo+IHRoYXQgd29yayBoYXMgYmVlbiBkb25lIG9uIGl0 IHNpbmNlIGl0IHdhcyBwdWJsaXNoZWQuDQo+IFNvbWVib2R5IHNob3VsZCBhc2sgKG51ZGdlLW51 ZGdlKSBNU0ZULi4uIChsZWlmKQ0KDQpodHRwOi8vbXNkbi5taWNyb3NvZnQuY29tL2VuLXVzL2xp YnJhcnkvZGQzMDM1NzYocHJvdC4yMCkuYXNweCANCg0KU29tZSBvZiBpdCAoUGVyc2lzdGVudC1B dXRoIGhlYWRlcikgd2UgcmVwZWF0ZWQgaW4gb3VyIG11bHRpbGVnZ2VkIGF1dGggZHJhZnQgYXZh aWxhYmxlIGZyb20gdGhlIGxpc3QgYWJvdmUuDQoNClRoYW5rcywNCg0KR2FicmllbA0K From julian.reschke@gmx.de Sat Oct 13 03:49:52 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 EA75521F8534 for ; Sat, 13 Oct 2012 03:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=-0.944, 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 l046EvTTinnF for ; Sat, 13 Oct 2012 03:49:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 83B4221F8533 for ; Sat, 13 Oct 2012 03:49:51 -0700 (PDT) Received: (qmail invoked by alias); 13 Oct 2012 10:49:49 -0000 Received: from p5DD94FF7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.79.247] by mail.gmx.net (mp029) with SMTP; 13 Oct 2012 12:49:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+54bweUB257eOD6UR55oIZOl3ZyZUc0/mD31T4gH ZTk7JmcLpM/XKn Message-ID: <50794742.3010902@gmx.de> Date: Sat, 13 Oct 2012 12:49:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lucy Lynch References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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: Sat, 13 Oct 2012 10:49:53 -0000 On 2012-10-12 20:07, Lucy Lynch wrote: > On Fri, 5 Oct 2012, Yoav Nir wrote: > >> Hi all >> >> The preliminary agenda is now posted at >> https://datatracker.ietf.org/meeting/85/agenda.txt , as well as at >> http://tools.ietf.org/agenda/85/ >> >> Either way, we are currently scheduled to meet at 13:00 on Wednesday, >> 7-Nov, in Grand Ballroom D. We have 1.5 hours to go. Note that we >> cannot guarantee that the scheduling will not change, but it is not >> likely to, and we'll do our best to keep it on Wednesday. >> >> We propose the following agenda: >> - 13:00-13:05 Blue sheets, Note Well and agenda bashing >> - 13:05-13:20 Introduction and problem statement >> - 13:20-14:00 (Short!!!) presentations on the candidates >> - 14:00-14:30 Charter hack, and the usual BoF questions >> >> People with candidate documents, who wish to present at the session >> should do the following: > > just as an aide mémoire the following documents have been mentioned > on the BOF thread: > > - draft-oiwa-* > - draft-farrell-httpbis-hoba > - draft-melnikov-httpbis-scram-auth > - draft-williams-httpbis-auth-classification > - draft-ahrens-httpbis-digest-auth-update (sean) > > - Note: Actually, please include draft-williams-http-rest-auth > (RESTauth, successor to REST-GSS) and remove > draft-williams-httpbis-auth-classification. (nico) > > - What about Negotiate? Its already an informational RFC but I have > a hunch that work has been done on it since it was published. > Somebody should ask (nudge-nudge) MSFT... (leif) > > - http://www.w3.org/2012/webcrypto/WebCryptoAPI/ (harry) > > - There is a proposal in HTML5 for enhancing form support of HTTP which > includes 'mapping' username\passwords into the same XHR.open() > functionality. Also included is a method for clearing the auth cache > on successful response which integrates with a HTTP request for server > notification and cookie clearing: > http://www.w3.org/wiki/User:Cjones/ISSUE-195 (cameron) > > Also - > > - active discussion on I18n but no documents listed > ... http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-06.html Best regards, Julian From leifj@mnt.se Sun Oct 14 03:06:56 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 3A91221F8504 for ; Sun, 14 Oct 2012 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 yphwvFSxWvuu for ; Sun, 14 Oct 2012 03:06:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6718121F8503 for ; Sun, 14 Oct 2012 03:06:49 -0700 (PDT) Received: from [10.33.1.163] ([212.247.15.226]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q9EA6fuf014909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Oct 2012 12:06:45 +0200 (CEST) Message-ID: <507A8EB1.4080708@mnt.se> Date: Sun, 14 Oct 2012 12:06:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: http-auth@ietf.org References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [http-auth] BoF in Atlanta 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, 14 Oct 2012 10:06:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2012 01:08 AM, Gabriel Montenegro wrote: > Hi Lucy, > > >> just as an aide mémoire the following documents have been >> mentioned on the BOF thread: > > Your list was not complete. This list has them all: > http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals > >> - What about Negotiate? Its already an informational RFC but I >> have a hunch that work has been done on it since it was >> published. Somebody should ask (nudge-nudge) MSFT... (leif) > > http://msdn.microsoft.com/en-us/library/dd303576(prot.20).aspx > > Some of it (Persistent-Auth header) we repeated in our multilegged > auth draft available from the list above. > Still, that isn't listed on the wiki-page. Also absent is my HTTP GSS proposal (expired) http://datatracker.ietf.org/doc/draft-johansson-http-gss/ Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB6jrEACgkQ8Jx8FtbMZneMFwCfSPWNOAaPeKbxvKe1pBNpTeuZ TqcAnRTLX9syVaZJksJrVtxovqDU7Hb0 =X8O+ -----END PGP SIGNATURE----- From Gabriel.Montenegro@microsoft.com Sun Oct 14 14:11:43 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 8135521F84F1 for ; Sun, 14 Oct 2012 14:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599] 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 LMVQ0-DAD+S3 for ; Sun, 14 Oct 2012 14:11:37 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id AF36021F84EF for ; Sun, 14 Oct 2012 14:11:36 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.161.201) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.516.0; Sun, 14 Oct 2012 21:12:27 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Sun, 14 Oct 2012 21:12:27 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 14 Oct 2012 21:11:24 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.147]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Sun, 14 Oct 2012 14:11:23 -0700 From: Gabriel Montenegro To: Leif Johansson , "http-auth@ietf.org" Thread-Topic: [http-auth] BoF in Atlanta Thread-Index: Ac2jFdBVJFyIXs1fRkqBU3ebORxHxgFyUJ2AAARUKTAAT3kKgAACkgRA Date: Sun, 14 Oct 2012 21:11:23 +0000 Message-ID: References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> <507A8EB1.4080708@mnt.se> In-Reply-To: <507A8EB1.4080708@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(16696001)(8716001)(5343635001)(50986001)(1076001)(74662001)(47446002)(51856001)(47776002)(46102001)(44976002)(49866001)(15202345001)(74502001)(33656001)(31966008)(42186003)(16826001)(5343655001)(4396001)(3846001)(48376001)(16406001)(47976001)(47736001)(4196001)(20776001)(50466001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0634F37BFF Subject: Re: [http-auth] BoF in Atlanta 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, 14 Oct 2012 21:11:43 -0000 DQo+ID4+IC0gV2hhdCBhYm91dCBOZWdvdGlhdGU/IEl0cyBhbHJlYWR5IGFuIGluZm9ybWF0aW9u YWwgUkZDIGJ1dCBJIGhhdmUgYQ0KPiA+PiBodW5jaCB0aGF0IHdvcmsgaGFzIGJlZW4gZG9uZSBv biBpdCBzaW5jZSBpdCB3YXMgcHVibGlzaGVkLiBTb21lYm9keQ0KPiA+PiBzaG91bGQgYXNrIChu dWRnZS1udWRnZSkgTVNGVC4uLiAobGVpZikNCj4gPg0KPiA+IGh0dHA6Ly9tc2RuLm1pY3Jvc29m dC5jb20vZW4tdXMvbGlicmFyeS9kZDMwMzU3Nihwcm90LjIwKS5hc3B4DQo+ID4NCj4gPiBTb21l IG9mIGl0IChQZXJzaXN0ZW50LUF1dGggaGVhZGVyKSB3ZSByZXBlYXRlZCBpbiBvdXIgbXVsdGls ZWdnZWQNCj4gPiBhdXRoIGRyYWZ0IGF2YWlsYWJsZSBmcm9tIHRoZSBsaXN0IGFib3ZlLg0KPiA+ DQo+IA0KPiBTdGlsbCwgdGhhdCBpc24ndCBsaXN0ZWQgb24gdGhlIHdpa2ktcGFnZS4gQWxzbyBh YnNlbnQgaXMgbXkgSFRUUCBHU1MgcHJvcG9zYWwNCj4gKGV4cGlyZWQpDQoNClRoZSBtdWx0aWxl Z2dlZCBkcmFmdCAqaXMqIGxpc3RlZCBvbiB0aGUgd2lraSBwYWdlIHdoZXJlIGl0IHNheXM6DQoN Ck11bHRpbGVnZ2VkIEF1dGhlbnRpY2F0aW9uIGZvciBIVFRQIE11bHRpcGxleGluZyANClRoZSB1 cmw6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vbnRlbmVncm8taHR0cGJpcy1t dWx0aWxlZ2dlZC1hdXRoLw0KDQoNCg== From leifj@mnt.se Sun Oct 14 14:24:10 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 601F921F8480 for ; Sun, 14 Oct 2012 14:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 2pARl8MHMMsD for ; Sun, 14 Oct 2012 14:24:09 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F114921F8475 for ; Sun, 14 Oct 2012 14:24:08 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q9ELNxNi015163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Oct 2012 23:24:03 +0200 (CEST) Message-ID: <507B2D6E.1090503@mnt.se> Date: Sun, 14 Oct 2012 23:23:58 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Gabriel Montenegro References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> <507A8EB1.4080708@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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, 14 Oct 2012 21:24:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/2012 11:11 PM, Gabriel Montenegro wrote: > >>>> - What about Negotiate? Its already an informational RFC but >>>> I have a hunch that work has been done on it since it was >>>> published. Somebody should ask (nudge-nudge) MSFT... (leif) >>> >>> http://msdn.microsoft.com/en-us/library/dd303576(prot.20).aspx >>> >>> Some of it (Persistent-Auth header) we repeated in our >>> multilegged auth draft available from the list above. >>> >> >> Still, that isn't listed on the wiki-page. Also absent is my HTTP >> GSS proposal (expired) > > The multilegged draft *is* listed on the wiki page where it says: > > Multilegged Authentication for HTTP Multiplexing The url: > http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth/ > > > I wasn't talking about http-multilegged. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB7LW4ACgkQ8Jx8FtbMZneb4ACfdtoSmLqUa6YFcMBGxDpt7RsC SnMAoMn6Kp3k7H4id9zmUc00X4Qcoogu =UStT -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Sun Oct 14 14:25:33 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 A858321F84F6 for ; Sun, 14 Oct 2012 14:25:33 -0700 (PDT) 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 oxfbYWN+yiwl for ; Sun, 14 Oct 2012 14:25:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 924B421F84F3 for ; Sun, 14 Oct 2012 14:25:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D9049171476; Sun, 14 Oct 2012 22:25:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350249930; bh=xTxVh59eFyoQQY 3syyX6kYdQSf5xp0A7J7snVOV3doA=; b=3Ujz/gqG4lFmVbj4TYNkb8X2PuIV0f AVhyfozVT7a25bEIac2FXqE6iyQCDQT0huM6iFENEAT5zOiPm8EdvO5v6IlNKyu9 o95L8s9U7qDTEyyvgd2rr4h8BfqwYA87dTKswHxsRCXKdLxCngcLEOYbS8nBsl4N P9q2SCowWqrQQT5AlO4qmxn3XmpAgexj9E9KnjSUZ9XiRQrddw2dRTiI79okJ4cP iMTZqEib++iB3mPbWT80vCxa6cXeC/j8x6HUoIt5n4fba8r6hrUgBTcIj3Zhe85k I9ZjQryIb9HBmJ+j1gpXsRBKgCUzbGS3oCRU7iY5cplCux79kyI7Ehkg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id i7EYE601Xxh8; Sun, 14 Oct 2012 22:25:30 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.24.58]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3DD49171471; Sun, 14 Oct 2012 22:25:28 +0100 (IST) Message-ID: <507B2DC7.1040603@cs.tcd.ie> Date: Sun, 14 Oct 2012 22:25:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Yoav Nir References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> In-Reply-To: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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, 14 Oct 2012 21:25:33 -0000 Yoav, Speaking solely as a proponent of one of the proposals, and not as an AD... My hope is that if we do form a wg that it'll not be with a goal of picking winners amongst the various proposals, but rather of getting those of 'em that are sensible, have enough author-energy etc. to become experimental RFCs (or better I suppose in the case of wild success). And those can then all individually prosper or wither as determined by adoption or lack thereof. Does that match others' expectations for Atlanta? Cheers, S. PS: Since I am a proponent of one proposal, I've made it clear to Sean and the BoF chairs that I'll not be AD-like at all where this BoF is concerned. On 10/05/2012 05:23 PM, Yoav Nir wrote: > Hi all > > The preliminary agenda is now posted at https://datatracker.ietf.org/meeting/85/agenda.txt , as well as at http://tools.ietf.org/agenda/85/ > > Either way, we are currently scheduled to meet at 13:00 on Wednesday, 7-Nov, in Grand Ballroom D. We have 1.5 hours to go. Note that we cannot guarantee that the scheduling will not change, but it is not likely to, and we'll do our best to keep it on Wednesday. > > We propose the following agenda: > - 13:00-13:05 Blue sheets, Note Well and agenda bashing > - 13:05-13:20 Introduction and problem statement > - 13:20-14:00 (Short!!!) presentations on the candidates > - 14:00-14:30 Charter hack, and the usual BoF questions > > People with candidate documents, who wish to present at the session should do the following: > - Notify the chairs sooner rather than later > - Prepare a short presentation. > * You will only have a few minutes each and want to leave time for Q&A, so plan on no more than 5 minutes of presso. > * You don't each need to explain the problem. We'll do it in the introduction. > * You don't each need to explain what is the "HTTP authentication framework". > - Send slides to the chairs (PDF or PPT format) early - no later than Monday the 5th. > - If you would like to present, but will not be at the meeting, please contact us early so that we can arrange remote presentation or presentation by proxy. > > See you all there > > Derek & Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From ynir@checkpoint.com Sun Oct 14 15:06:13 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 AA29521F84FC for ; Sun, 14 Oct 2012 15:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 T7Wp56h625YI for ; Sun, 14 Oct 2012 15:06:13 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A0AF221F8447 for ; Sun, 14 Oct 2012 15:06:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9EM684b013618; Mon, 15 Oct 2012 00:06:08 +0200 X-CheckPoint: {507B35AA-0-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Oct 2012 00:05:52 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 15 Oct 2012 00:05:52 +0200 From: Yoav Nir To: Stephen Farrell Date: Mon, 15 Oct 2012 00:05:50 +0200 Thread-Topic: [http-auth] BoF in Atlanta Thread-Index: Ac2qWBKxPcliFAX5TEq2yTqYEL35Aw== Message-ID: <1B0CAD68-EA7A-45A6-AD10-167CE96A3228@checkpoint.com> References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> <507B2DC7.1040603@cs.tcd.ie> In-Reply-To: <507B2DC7.1040603@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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, 14 Oct 2012 22:06:13 -0000 On Oct 14, 2012, at 11:25 PM, Stephen Farrell wrote: >=20 > Yoav, >=20 > Speaking solely as a proponent of one of the > proposals, and not as an AD... >=20 > My hope is that if we do form a wg that it'll not > be with a goal of picking winners amongst the > various proposals, but rather of getting those of > 'em that are sensible, have enough author-energy > etc. to become experimental RFCs (or better I > suppose in the case of wild success). And those > can then all individually prosper or wither as > determined by adoption or lack thereof. >=20 > Does that match others' expectations for Atlanta? Hi Stephen. It matches the instructions we got from Sean, and it matches my expectation= s personally. The plan is to have short presentations on the 5 proposals (or "candidates"= ). We have received confirmations from 3 groups (including yours) and shoul= d soon know definitely about the other two. Then we plan to discuss the cha= rter: First, I'd like to make sure that enough people believe that pursuing authe= ntication methods in the HTTP layer is worthwhile (as opposed to other laye= rs) and are willing to work in that space. I think this is an important que= stion to ask, because "Basic" and "Digest" have been available for many yea= rs, and they were unused in favor of application-layer methods that were no= more secure than "Basic".=20 Assuming we have a large enough group that is willing to do work in general= in this area, the second step is to go over the proposed charter - see tha= t people are OK with a bunch of experimental drafts, where we don't intend = to pick the one and only ultimate authentication mechanism for HTTP. Once that is out of the way, we'll go over the 5 candidates, and ask the re= gular questions (does anyone object to the wg adding this to the charter? W= ho is willing to edit? contribute? review?) To consider this a success, I think we should come out of the BOF with at l= east three drafts for the working group, and 5 would be OK as well. I also think such a working group should develop an informational document = about UI considerations for HTTP authentication, but we'll leave it out for= now, because I don't think there will be time to discuss such a document. Yoav From llynch@civil-tongue.net Mon Oct 15 07:19:02 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 3C9A51F0425 for ; Mon, 15 Oct 2012 07:19:02 -0700 (PDT) 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 ncq6feS4j+dm for ; Mon, 15 Oct 2012 07:19:01 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id D01431F041F for ; Mon, 15 Oct 2012 07:19:01 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id q9FEJ1vj056701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Oct 2012 07:19:01 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id q9FEJ07q056698 for ; Mon, 15 Oct 2012 07:19:01 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Mon, 15 Oct 2012 07:19:00 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: http-auth@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Subject: Re: [http-auth] BoF in Atlanta 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, 15 Oct 2012 14:19:02 -0000 On Fri, 12 Oct 2012, Gabriel Montenegro wrote: > Hi Lucy, > > >> just as an aide mémoire the following documents have been mentioned on >> the BOF thread: > > Your list was not complete. This list has them all: > http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals Right, my list was based on items mentioned in the BOF thread on the http-auth list. The two lists are slightly different. >> - What about Negotiate? Its already an informational RFC but I have a hunch >> that work has been done on it since it was published. >> Somebody should ask (nudge-nudge) MSFT... (leif) > > http://msdn.microsoft.com/en-us/library/dd303576(prot.20).aspx > > Some of it (Persistent-Auth header) we repeated in our multilegged auth draft > available from the list above. > > Thanks, > > Gabriel > From turners@ieca.com Thu Oct 18 05:37:29 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 0887B21F872A for ; Thu, 18 Oct 2012 05:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.447 X-Spam-Level: X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 ZlyrVd953uzD for ; Thu, 18 Oct 2012 05:37:28 -0700 (PDT) Received: from gateway05.websitewelcome.com (unknown [64.5.52.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B321F8745 for ; Thu, 18 Oct 2012 05:37:28 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 1102E578C5FA8; Thu, 18 Oct 2012 07:37:28 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 02A99578C5F6F for ; Thu, 18 Oct 2012 07:37:28 -0500 (CDT) Received: from [96.241.97.104] (port=61312 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TOpLr-0005ru-Mc; Thu, 18 Oct 2012 07:37:27 -0500 Message-ID: <507FF807.8010008@ieca.com> Date: Thu, 18 Oct 2012 08:37:27 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Yoav Nir References: <8AEEA404-CC7C-4487-BE7D-99CBAA8BC48F@checkpoint.com> <507B2DC7.1040603@cs.tcd.ie> <1B0CAD68-EA7A-45A6-AD10-167CE96A3228@checkpoint.com> In-Reply-To: <1B0CAD68-EA7A-45A6-AD10-167CE96A3228@checkpoint.com> 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) [96.241.97.104]:61312 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF in Atlanta 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, 18 Oct 2012 12:37:29 -0000 On 10/14/12 6:05 PM, Yoav Nir wrote: > > On Oct 14, 2012, at 11:25 PM, Stephen Farrell wrote: > >> >> Yoav, >> >> Speaking solely as a proponent of one of the >> proposals, and not as an AD... >> >> My hope is that if we do form a wg that it'll not >> be with a goal of picking winners amongst the >> various proposals, but rather of getting those of >> 'em that are sensible, have enough author-energy >> etc. to become experimental RFCs (or better I >> suppose in the case of wild success). And those >> can then all individually prosper or wither as >> determined by adoption or lack thereof. >> >> Does that match others' expectations for Atlanta? > > Hi Stephen. > > It matches the instructions we got from Sean, and it matches my expectations personally. > > The plan is to have short presentations on the 5 proposals (or "candidates"). We have received confirmations from 3 groups (including yours) and should soon know definitely about the other two. Then we plan to discuss the charter: > > First, I'd like to make sure that enough people believe that pursuing authentication methods in the HTTP layer is worthwhile (as opposed to other layers) and are willing to work in that space. I think this is an important question to ask, because "Basic" and "Digest" have been available for many years, and they were unused in favor of application-layer methods that were no more secure than "Basic". > > Assuming we have a large enough group that is willing to do work in general in this area, the second step is to go over the proposed charter - see that people are OK with a bunch of experimental drafts, where we don't intend to pick the one and only ultimate authentication mechanism for HTTP. > > Once that is out of the way, we'll go over the 5 candidates, and ask the regular questions (does anyone object to the wg adding this to the charter? Who is willing to edit? contribute? review?) > > To consider this a success, I think we should come out of the BOF with at least three drafts for the working group, and 5 would be OK as well. I tend to think 3 here would be good as well. spt > I also think such a working group should develop an informational document about UI considerations for HTTP authentication, but we'll leave it out for now, because I don't think there will be time to discuss such a document. > > Yoav > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From hallam@gmail.com Fri Oct 19 20:23:33 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 0E54021F889F for ; Fri, 19 Oct 2012 20:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-1.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] 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 rSKFqLCbYeNM for ; Fri, 19 Oct 2012 20:23:32 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA11921F859E for ; Fri, 19 Oct 2012 20:23:31 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1249632oag.31 for ; Fri, 19 Oct 2012 20:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wEsc6j74e6F/X1cRZWMlmWjNTU8zLxExaRSXGfxpH+8=; b=Dd20cWYKhWBCiLus2+WWZkTOhO2yRz7kIg8KubPf+yVSOKDmJnY4GqiKaONAC9TOS6 9qydnnwKTHyFR+g5ormBjRQIbi7NTyI9z4znGLoR7J/OPYXV9VWL07nqj1GxFgAQy37p 6JbqlVTeRLueLApOe1xalrU+jMZfFbiEQzZHvmpdftkdpPiJicn5VlBh9rVfdVoUPvCu 1KBwHqbRyp2y93JQFpW+n2bWvqx4NUSEcBPQwP4E2pG6wlhImBf4olndZ+Iph7r5CxnY EOCQzpQnYwpVvN5SEOkNoCiCN/2IN65MMSEkEY1goW3hoC4QFDg7ba9z1A/Q71UeFbLZ o+Kg== MIME-Version: 1.0 Received: by 10.182.5.168 with SMTP id t8mr2032007obt.32.1350703411544; Fri, 19 Oct 2012 20:23:31 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 19 Oct 2012 20:23:31 -0700 (PDT) Date: Fri, 19 Oct 2012 23:23:31 -0400 Message-ID: From: Phillip Hallam-Baker To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=f46d044795a50ac3a704cc7525f2 Subject: [http-auth] HTTP Integrity Header 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: Sat, 20 Oct 2012 03:23:33 -0000 --f46d044795a50ac3a704cc7525f2 Content-Type: text/plain; charset=ISO-8859-1 I have a very, very minimal approach to HTTP Authentication. There are two parts to the description. Part 1 is now complete, this describes my proposal for a HTTP Integrity header. http://tools.ietf.org/html/draft-hallambaker-httpintegrity-01 Part 2 is currently largely in my head but I am working on completing a second draft which explains the rationale. The basic idea here is that there are two parts to an authentication scheme. One part is all the mucking about establishing keys and identifiers. That has a lot of complexity and there is a lot of need for variation. In particular the needs of user authentication and Web Service authentication are very different. There is also a need to engage with and interact with a huge amount of legacy. When I look at that problem I conclude that it is not going to be a one size fits all solution, there will be multiple solutions meeting different needs. We are not even going to get everyone to agree on a single framework. It also looks to me to be a problem that is at a different layer to HTTP. It is out in Web Service or HTML space. The second problem is how those keys and algorithms and such are applied to parts of HTTP messages (e.g. the content) and how the resulting authentication value (MAC, digital signature, etc.) is bundled into the HTTP space. Now that is a problem that I think can be addressed in HTTP with a great deal of generality. And that is what the integrity header does. This is an example of the header being used in a real Web Service example. Host: example.com Cache-Control: no-store Content-Type: Application/json;charset=UTF-8 Content-Length: 78 Integrity: content=true; value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=; id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4 oB29dgs/ei6ieINZtmvXNCm2NUkWA== { "TicketRequest": { "ChallengeResponse": "TctLOG74cwpm26YNpEibcQ=="}} Note that what we are achieving here is remarkably close to what SOAP plus WS-Security are meant to do but with a dramatic reduction in complexity. And only a little of that comes from using JSON instead of XML. Specifically we avoid the need for: 1) XPATH The scope of the authentication is the HTTP content. 2) Canonicalization: The bits authenticated are the same bits that the application would see after chunked encoding (or other transfer encoding) is stripped out. 3) Transformation: There is no need to embed the signature inside an XML anything because the MAC value goes in a slot that is completely separate from the data we are signing and is not going to be confusealized. 4) WS-Security: All those options go poof. 5) SOAP: Not needed, the only need for SOAP in most Web Services is to have a slot for the WS-Security info anyway. 6) Algorithm identifiers: Those are not something that HTTP needs to understand. They are present in the above message but they are opaque to the HTTP layer which does not need to understand them. 7) Certificate Paths etc.: Again they can be used but they don't belong at the HTTP layer. They would be part of SAML or OAUTH or OpenID which might be leveraging this header as a better way to bind the authentication token to the HTTP transport than stuffing it into a cookie and hoping that BEAST or CRIME type approaches can't extract it. -- Website: http://hallambaker.com/ --f46d044795a50ac3a704cc7525f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a very, very minimal approach to HTTP Authentication. There are two = parts to the description. Part 1 is now complete, this describes my proposa= l for a HTTP Integrity header.

http://tools.ietf.org/html= /draft-hallambaker-httpintegrity-01

Part 2 is currently largely in my head but I am wo= rking on completing a second draft which explains the rationale.
=
The basic idea here is that there are two parts to an authen= tication scheme. One part is all the mucking about establishing keys and id= entifiers. That has a lot of complexity and there is a lot of need for vari= ation. In particular the needs of user authentication and Web Service authe= ntication are very different. There is also a need to engage with and inter= act with a huge amount of legacy.

When I look at that problem I conclude that it is not g= oing to be a one size fits all solution, there will be multiple solutions m= eeting different needs. We are not even going to get everyone to agree on a= single framework. It also looks to me to be a problem that is at a differe= nt layer to HTTP. It is out in Web Service or HTML space.=A0


The second problem is how those keys and= algorithms and such are applied to parts of HTTP messages (e.g. the conten= t) and how the resulting authentication value (MAC, digital signature, etc.= ) is bundled into the HTTP space.

Now that is a problem that I think can be addressed in = HTTP with a great deal of generality. And that is what the integrity header= does.=A0


This is an example of the= header being used in a real Web Service example.

=A0 =A0 =A0 oB29dgs/ei6ieINZtmvXNCm2NUkWA=3D=3D

{


Note that what we are achieving here is remarkably close to what= SOAP plus WS-Security are meant to do but with a dramatic reduction in com= plexity. And only a little of that comes from using JSON instead of XML. Sp= ecifically we avoid the need for:

1) XPATH The scope of the authentication is the HTTP co= ntent.=A0

2) Canonicalization: The bits authentica= ted are the same bits that the application would see after chunked encoding= (or other transfer encoding) is stripped out.=A0

3) Transformation: There is no need to embed the signat= ure inside an XML anything because the MAC value goes in a slot that is com= pletely separate from the data we are signing and is not going to be confus= ealized.

4) WS-Security: All those options go poof.
5) SOAP: Not needed, the only need for SOAP in most Web Servic= es is to have a slot for the WS-Security info anyway.

6) Algorithm identifiers: Those are not something that HTTP needs to u= nderstand. They are present in the above message but they are opaque to the= HTTP layer which does not need to understand them.=A0

7) Certificate Paths etc.: Again they can be used but they don't b= elong at the HTTP layer. They would be part of SAML or OAUTH or OpenID whic= h might be leveraging this header as a better way to bind the authenticatio= n token to the HTTP transport than stuffing it into a cookie and hoping tha= t BEAST or CRIME type approaches can't extract it.



--
Website: http://hallambaker.com/

--f46d044795a50ac3a704cc7525f2-- From hallam@gmail.com Mon Oct 22 13:24:43 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 9AAB821F8519 for ; Mon, 22 Oct 2012 13:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 jCVaDG2058h3 for ; Mon, 22 Oct 2012 13:24:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBC21F8530 for ; Mon, 22 Oct 2012 13:24:42 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3406195obq.31 for ; Mon, 22 Oct 2012 13:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pdwWR5CZr3nM/I3bJ9b5Iub9qmQ0AIBLrZidQpCF01o=; b=SXDWuyry3v0v/bc5SB1ValofIgIk1uDV009H8xKh8QVcauaGKw+hEtMt+ozpzBTp8h jUkjCThqqdhazJr02/W3HyeOd6fyD0qMhbR0muG4eHhiFqeAMnWkJZFreq3AbitiqNFw FOZvcR44Ejv6REhODbSqJAVyHYhqKkjKMEm8KqO9xfcghR0QhzgSEtRcIBjvnENKEvoz B68AxXfVpK9mvsrgTPMIuDKClIMMeeTh0vEwt0o5es79vGpiEpEa5fc+eQz8GYVTAYcF BtmtgPY9cR+187WmmIPQ438O5Kz14wUzKTHOQQI6BTwqH//CA+d10Oe4FlEnJqBVL2rE 039w== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr7986885obb.98.1350937481652; Mon, 22 Oct 2012 13:24:41 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Mon, 22 Oct 2012 13:24:41 -0700 (PDT) Date: Mon, 22 Oct 2012 16:24:41 -0400 Message-ID: From: Phillip Hallam-Baker To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=f46d04463078b528c304ccaba448 Subject: [http-auth] My submission to the HTTP-Auth Working group 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, 22 Oct 2012 20:24:43 -0000 --f46d04463078b528c304ccaba448 Content-Type: text/plain; charset=ISO-8859-1 My analysis of the situation and a plan of action is set out in: http://tools.ietf.org/html/draft-hallambaker-httpauth-01 Now be warned that the prose style is somewhat interesting, if not angry. Rest assured that if your sacred cow is one of the ones I have thrown on the grill then you will find plenty alongside. The worst thing we can do here is to try to solve this problem by doing exactly what we have done before but in JSON rather than XML. Rewriting SAML in JSON would be fun and is probably inevitable, its the thing we do well. But thats not going to be a solution. -- Website: http://hallambaker.com/ --f46d04463078b528c304ccaba448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My analysis of the situation and a plan of action is set out in:
=

http://tools.ietf.org/html/draft-hallambaker-httpauth-01

Now be warned that the prose style is somewhat interesting, = if not angry. Rest assured that if your sacred cow is one of the ones I hav= e thrown on the grill then you will find plenty alongside.

The worst thing we can do here is to try to solve this problem b= y doing exactly what we have done before but in JSON rather than XML. Rewri= ting SAML in JSON would be fun and is probably inevitable, its the thing we= do well. But thats not going to be a solution.

--
Website: http://h= allambaker.com/

--f46d04463078b528c304ccaba448-- From ynir@checkpoint.com Thu Oct 25 04:45: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 E3FA021F890B for ; Thu, 25 Oct 2012 04:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.586 X-Spam-Level: X-Spam-Status: No, score=-10.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iJe6Ol9cHQ2I for ; Thu, 25 Oct 2012 04:45:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC94721F88E8 for ; Thu, 25 Oct 2012 04:45:49 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9PBjj4G023364 for ; Thu, 25 Oct 2012 13:45:45 +0200 X-CheckPoint: {50892449-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 25 Oct 2012 13:45:45 +0200 From: Yoav Nir To: "http-auth@ietf.org" Date: Thu, 25 Oct 2012 13:45:44 +0200 Thread-Topic: HTTP-Auth Preliminary Agenda and Reading List Thread-Index: Ac2ypkSiD5RIMBxHSNq069t/AfP5aw== Message-ID: <15D7FD90-E565-449E-94AF-1433FCC9F60C@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] HTTP-Auth Preliminary Agenda and Reading List 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, 25 Oct 2012 11:45:52 -0000 Hi all I have uploaded the preliminary agenda for the httpauth meeting, also paste= d below. As you can see, the schedule is very tight, especially with the 5 proposal = presentations, each lasting 5 minutes, with 3 minutes allocated for discuss= ion. Please come prepared, as you'll be asked to speak about the charter, a= nd to commit to contributing/reviewing the proposals. The proposed charter is here: http://www.ietf.org/mail-archive/web/http-auth/current/msg01028.html To quote from this: "All schemes to be developed in the http-auth WG must b= e usable with the existing HTTP authentication framework". Please read abou= t the framework in section 2 of draft-ietf-httpbis-p7-auth: http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-21#section-2 The proposals themselves are here: http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals See you all there. Yoav Here's the preliminary agenda: IETF-85 HTTPAUTH BOF Wednesday, November 7, 13:00-14:30 ---------------------------------- 1. Note Well, Agenda, Note Takers, Blue sheets (5 min) 2. Problem Statement (10 min) - Chairs 3. 5 presentations (40 min) - Farrell, Oiwa, Williams, Melnikov, Montenegro 4. Charter Bashing + gauging general interest (15 min) 5. Show of hands about the particular proposals (20 min) From pauljleach@msn.com Wed Oct 31 18:19:15 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 1A79921F864A for ; Wed, 31 Oct 2012 18:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 wG61UIt3-gsO for ; Wed, 31 Oct 2012 18:19:14 -0700 (PDT) Received: from snt0-omc3-s19.snt0.hotmail.com (snt0-omc3-s19.snt0.hotmail.com [65.55.90.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4117121F8646 for ; Wed, 31 Oct 2012 18:19:14 -0700 (PDT) Received: from SNT144-DS5 ([65.55.90.137]) by snt0-omc3-s19.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 18:19:13 -0700 X-Originating-IP: [70.19.82.236] X-EIP: [1ITWxoYyROBLWmkymup1tBsXO6L67bLL] X-Originating-Email: [pauljleach@msn.com] Message-ID: From: "Paul Leach" To: Date: Wed, 31 Oct 2012 21:19:10 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01CDB7AD.5E536000" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 01 Nov 2012 01:19:13.0904 (UTC) FILETIME=[E7856F00:01CDB7CE] Subject: [http-auth] My list of issues to be tackled in http auth framework 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, 01 Nov 2012 01:19:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009B_01CDB7AD.5E536000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In this post I undertake to outline issues with which an authentication = framework for HTTP needs to deal. I do so by sketching the typical behavior of many authentication = protocols in setting up and using secure sessions, then relating it to = the HTTP context. A typical authentication protocol initially exchanges a few messages = between client and server, which securely identifies the requestor (and = sometimes the server) and which arrives at a mutually agreed upon key = for the session, after which the key is used to provide authentication = and/or confidentiality for subsequent application protocol traffic on = that session. The session also typically provides replay prevention. = Some schemes provide optimized session re-establishment if the = underlying transport connection is dropped. HTTP issues The key agreement phase requires that state be kept between messages, = and the HTTP authentication framework [RFC 2617] provides no mechanism = for associating requests with an authentication session. (Individual = authentication schemes can provide their own, but this complicates = addition of new schemes.) Since proxies may have more than one = connection to an origin server, and may forward requests from a client = along any of them, transport connections can not be used for this = purpose. (And with multiplexing in HTTP/2.0, it doesn't even require a = proxy to create this problem -- a single client-server connection can = have it.) After key agreement, the key and any information needed for replay = prevention are session state, and present the same problem. Even in the absence of proxies, transport connections may be dropped at = any time. The effectiveness of optimized session re-establishment = depends on the session being usually re-established on the same system = as it was initially established. There is no support for authenticating chunked entity bodies. Without = chunking, long messages can't be authenticated until the whole message = arrives. If the bodies are large, just buffering them can be = problematic, and the inability to interleace reception and = authentication adds to latency. If the bodies are indefinite length, = authentication is not possible. The mechanism for negotiating authentication schemes is not protected; = this means that a MITM attacker can cause the client and server to = select the weakest mutually supported authentication scheme. In = principle, the weakest scheme should be strong enough, but in practice = the desire for interoperability leads to overly weak schemes being = offered. =20 POST (and other) requests containing large entity bodies are problematic = when the client doesn't know whether authentication will be required for = the target resource. For performance reasons, they don't want to include = the entity body with each authentication message, yet they can't omit = the body in the initial request because authentication might not be = required (in which case the request would succeed using the empty body). The syntax for the content of authentication messages is scheme-specific = and visible to the HTTP stack implementation. This makes addition of new = authentication schemes more intrusive than it might be (contrast with = SASL [RFC 4422], where they are encoded as a single opaque string). HTTP is often carried over TLS, and can be leveraged to avoid all but = the last two of the above issues (with proper channel binding [RFC5056, = RFC5929] support). However, unless its use is mandatory for all = client-authenticated connections, all the issues would still need to be = dealt with. Conclusion I've tried to list all the issues I can think of with the HTTP = authentication framework as currently specified. Comments and additions = are welcome. ------=_NextPart_000_009B_01CDB7AD.5E536000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In this post I undertake to outline issues with which an = authentication=20 framework for HTTP needs to deal.
 
I do so by sketching the typical behavior of many authentication = protocols=20 in setting up and using secure sessions, then relating it to the HTTP=20 context.
 
A typical authentication protocol initially exchanges a few = messages=20 between client and server, which securely identifies the requestor (and=20 sometimes the server) and which arrives at a mutually agreed upon key = for the=20 session, after which the key is used to provide authentication and/or=20 confidentiality for subsequent application protocol traffic on that = session. The=20 session also typically provides replay prevention. Some schemes provide=20 optimized session re-establishment if the underlying transport = connection is=20 dropped.
 
HTTP issues
 
The key agreement phase requires that state be kept between = messages, and=20 the HTTP authentication framework [RFC 2617] provides no mechanism for=20 associating requests with an authentication session. (Individual = authentication=20 schemes can provide their own, but this complicates addition of new = schemes.)=20 Since proxies may have more than one connection to an origin server, and = may=20 forward requests from a client along any of them, transport connections = can not=20 be used for this purpose. (And with multiplexing in HTTP/2.0, it doesn't = even=20 require a proxy to create this problem -- a single client-server = connection can=20 have it.)
 
After key agreement, the key and any information needed for replay=20 prevention are session state, and present the same problem.
 
Even in the absence of proxies, transport connections may be = dropped at any=20 time. The effectiveness of optimized session re-establishment depends on = the=20 session being usually re-established on the same system as it was = initially=20 established.
 
There is no support for authenticating chunked entity bodies. = Without=20 chunking, long messages can't be authenticated until the whole message = arrives.=20 If the bodies are large, just buffering them can be problematic, and the = inability to interleace reception and authentication adds to latency. If = the=20 bodies are indefinite length, authentication is not possible.
 
The mechanism for negotiating authentication schemes is not = protected; this=20 means that a MITM attacker can cause the client and server to select the = weakest=20 mutually supported authentication scheme. In principle, the weakest = scheme=20 should be strong enough, but in practice the desire for interoperability = leads=20 to overly weak schemes being offered. 
 
POST (and other) requests containing large entity bodies are = problematic=20 when the client doesn't know whether authentication will be required for = the=20 target resource. For performance reasons, they don't want to include the = entity=20 body with each authentication message, yet they can't omit the body in = the=20 initial request because authentication might not be required (in which = case the=20 request would succeed using the empty body).
 
The syntax for the content of authentication messages is = scheme-specific=20 and visible to the HTTP stack implementation. This makes addition of new = authentication schemes more intrusive than it might be (contrast with = SASL [RFC=20 4422], where they are encoded as a single opaque string).
 
HTTP is often carried over TLS, and can be leveraged to avoid all = but the=20 last two of the above issues (with proper channel binding [RFC5056, = RFC5929]=20 support). However, unless its use is mandatory for all = client-authenticated=20 connections, all the issues would still need to be dealt with.
 
Conclusion
 
I've tried to list all the issues I can think of with the HTTP=20 authentication framework as currently specified.  Comments and = additions=20 are welcome.
 
 
 
 
 
------=_NextPart_000_009B_01CDB7AD.5E536000-- From hallam@gmail.com Wed Oct 31 18:30:15 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 8BBAE21F88D1 for ; Wed, 31 Oct 2012 18:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 fvYLGyAEOcbp for ; Wed, 31 Oct 2012 18:30:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46D21F86BE for ; Wed, 31 Oct 2012 18:30:14 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2241512obq.31 for ; Wed, 31 Oct 2012 18:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UYBBmXU/B+JLqzKUTyDgABxt9vYwehyKOl1GYGHMKXU=; b=vMMwxpNgFXE0aSGGH1pBWKDXpyZvjbC06T9Ym3VgeB7+l8to9QsKA2Wze4n9YiWS9P /OAhCRbAK8OfLMXpEJnZ/U8AzfvbCd7EZortmeGM5fNbkaQzvcR0tcXBWqRdM1J8wiqB ynkcS20C17iJ0YKGBr0ZevFle8PcYYOzT0GVcX3XIl1I8rZECIAktZe6E9mZcRLxW+MF skrDQYf5EOl9aGmLBm9n1Ugz1JjeIY0qthoEU+zxEXsajYcyy/YdxLDzPpuy4r+tBXhq ZDn1zKKe3zb+gK0Fc5t82vvlNL0sQLM9vyjb3duHrVC0oAUQPvcUVtpP6K7FdkHJU9nr 1YMg== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr32063434oec.36.1351733414058; Wed, 31 Oct 2012 18:30:14 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 31 Oct 2012 18:30:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Oct 2012 21:30:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Leach Content-Type: multipart/alternative; boundary=bcaec54a3e02f9db8c04cd64f5d3 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] My list of issues to be tackled in http auth framework 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, 01 Nov 2012 01:30:15 -0000 --bcaec54a3e02f9db8c04cd64f5d3 Content-Type: text/plain; charset=ISO-8859-1 Paul, I have a few more.... http://tools.ietf.org/html/draft-hallambaker-httpauth-01 On the chunked thing, well we did actually consider putting per chunk authentication in chunked. Problem is that a lot of the implementations have turned out to be fubar and so using chunked attributes is now deprecated. On the key exchange, I am not sure that is something that has to happen inside HTTP but the use of the established key certainly should. Reason for that is that there are many ways to exchange and associate keys. If we are doing a Web service we probably want to do it at the level of the Web service. But what we can't avoid doing is the binding to HTTP messages. One other point that I brought up in apps. I see a massive ice berg headed our way labelled Javascript privacy lawsuits. The fact is that the big holes in the Web security model are in the application layer and the parts that IETF has generally not wanted to look at. Today Javascript is a cess pit that enables a horror show of privacy violations. Pretty soon we are going to see that become a regulatory concern and it won't be pretty if we can't start fixing things. If we are going to fix things we have to start putting proper support in the browser for the types of feature that people use Javascript attrocities for. BTW, I just turned off Javascript by default earlier today, Web works a LOT better. On Wed, Oct 31, 2012 at 9:19 PM, Paul Leach wrote: > In this post I undertake to outline issues with which an authentication > framework for HTTP needs to deal. > > I do so by sketching the typical behavior of many authentication protocols > in setting up and using secure sessions, then relating it to the HTTP > context. > > A typical authentication protocol initially exchanges a few messages > between client and server, which securely identifies the requestor (and > sometimes the server) and which arrives at a mutually agreed upon key for > the session, after which the key is used to provide authentication and/or > confidentiality for subsequent application protocol traffic on that > session. The session also typically provides replay prevention. Some > schemes provide optimized session re-establishment if the underlying > transport connection is dropped. > > HTTP issues > > The key agreement phase requires that state be kept between messages, and > the HTTP authentication framework [RFC 2617] provides no mechanism for > associating requests with an authentication session. (Individual > authentication schemes can provide their own, but this complicates addition > of new schemes.) Since proxies may have more than one connection to an > origin server, and may forward requests from a client along any of them, > transport connections can not be used for this purpose. (And with > multiplexing in HTTP/2.0, it doesn't even require a proxy to create this > problem -- a single client-server connection can have it.) > > After key agreement, the key and any information needed for replay > prevention are session state, and present the same problem. > > Even in the absence of proxies, transport connections may be dropped at > any time. The effectiveness of optimized session re-establishment depends > on the session being usually re-established on the same system as it was > initially established. > > There is no support for authenticating chunked entity bodies. Without > chunking, long messages can't be authenticated until the whole message > arrives. If the bodies are large, just buffering them can be problematic, > and the inability to interleace reception and authentication adds to > latency. If the bodies are indefinite length, authentication is not > possible. > > The mechanism for negotiating authentication schemes is not protected; > this means that a MITM attacker can cause the client and server to select > the weakest mutually supported authentication scheme. In principle, the > weakest scheme should be strong enough, but in practice the desire for > interoperability leads to overly weak schemes being offered. > > POST (and other) requests containing large entity bodies are problematic > when the client doesn't know whether authentication will be required for > the target resource. For performance reasons, they don't want to include > the entity body with each authentication message, yet they can't omit the > body in the initial request because authentication might not be required > (in which case the request would succeed using the empty body). > > The syntax for the content of authentication messages is scheme-specific > and visible to the HTTP stack implementation. This makes addition of new > authentication schemes more intrusive than it might be (contrast with SASL > [RFC 4422], where they are encoded as a single opaque string). > > HTTP is often carried over TLS, and can be leveraged to avoid all but the > last two of the above issues (with proper channel binding [RFC5056, > RFC5929] support). However, unless its use is mandatory for all > client-authenticated connections, all the issues would still need to be > dealt with. > > Conclusion > > I've tried to list all the issues I can think of with the HTTP > authentication framework as currently specified. Comments and additions > are welcome. > > > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > -- Website: http://hallambaker.com/ --bcaec54a3e02f9db8c04cd64f5d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul,


On the chunked thing,= well we did actually consider putting per chunk authentication in chunked.= Problem is that a lot of the implementations have turned out to be fubar a= nd so using chunked attributes is now deprecated.



On the key exchange, I am= not sure that is something that has to happen inside HTTP but the use of t= he established key certainly should. Reason for that is that there are many= ways to exchange and associate keys. If we are doing a Web service we prob= ably want to do it at the level of the Web service. But what we can't a= void doing is the binding to HTTP messages.


One other point that I brought up in app= s. I see a massive ice berg headed our way labelled Javascript privacy laws= uits. The fact is that the big holes in the Web security model are in the a= pplication layer and the parts that IETF has generally not wanted to look a= t. Today Javascript is a cess pit that enables a horror show of privacy vio= lations.

Pretty soon we are going to see that become a regulator= y concern and it won't be pretty if we can't start fixing things.

If we are going to fix things we have to start putt= ing proper support in the browser for the types of feature that people use = Javascript attrocities for.


BTW, I just turned off Javascript by def= ault earlier today, Web works a LOT better.


On Wed, Oct 31, 2012 at 9:19 PM, Paul L= each <pauljleach@msn.com> wrote:
In this post I undertake to outline issues with which an authenticatio= n=20 framework for HTTP needs to deal.
=A0
I do so by sketching the typical behavior of many authentication proto= cols=20 in setting up and using secure sessions, then relating it to the HTTP=20 context.
=A0
A typical authentication protocol initially exchanges a few messages= =20 between client and server, which securely identifies the requestor (and=20 sometimes the server) and which arrives at a mutually agreed upon key for t= he=20 session, after which the key is used to provide authentication and/or=20 confidentiality for subsequent application protocol traffic on that session= . The=20 session also typically provides replay prevention. Some schemes provide=20 optimized session re-establishment if the underlying transport connection i= s=20 dropped.
=A0
HTTP issues
=A0
The key agreement phase requires that state be kept between messages, = and=20 the HTTP authentication framework [RFC 2617] provides no mechanism for=20 associating requests with an authentication session. (Individual authentica= tion=20 schemes can provide their own, but this complicates addition of new schemes= .)=20 Since proxies may have more than one connection to an origin server, and ma= y=20 forward requests from a client along any of them, transport connections can= not=20 be used for this purpose. (And with multiplexing in HTTP/2.0, it doesn'= t even=20 require a proxy to create this problem -- a single client-server connection= can=20 have it.)
=A0
After key agreement, the key and any information needed for replay=20 prevention are session state, and present the same problem.
=A0
Even in the absence of proxies, transport connections may be dropped a= t any=20 time. The effectiveness of optimized session re-establishment depends on th= e=20 session being usually re-established on the same system as it was initially= =20 established.
=A0
There is no support for authenticating chunked entity bodies. Without= =20 chunking, long messages can't be authenticated until the whole message = arrives.=20 If the bodies are large, just buffering them can be problematic, and the=20 inability to interleace reception and authentication adds to latency. If th= e=20 bodies are indefinite length, authentication is not possible.
=A0
The mechanism for negotiating authentication schemes is not protected;= this=20 means that a MITM attacker can cause the client and server to select the we= akest=20 mutually supported authentication scheme. In principle, the weakest scheme= =20 should be strong enough, but in practice the desire for interoperability le= ads=20 to overly weak schemes being offered.=A0
=A0
POST (and other) requests containing large entity bodies are problemat= ic=20 when the client doesn't know whether authentication will be required fo= r the=20 target resource. For performance reasons, they don't want to include th= e entity=20 body with each authentication message, yet they can't omit the body in = the=20 initial request because authentication might not be required (in which case= the=20 request would succeed using the empty body).
=A0
The syntax for the content of authentication messages is scheme-specif= ic=20 and visible to the HTTP stack implementation. This makes addition of new=20 authentication schemes more intrusive than it might be (contrast with SASL = [RFC=20 4422], where they are encoded as a single opaque string).
=A0
HTTP is often carried over TLS, and can be leveraged to avoid all but = the=20 last two of the above issues (with proper channel binding [RFC5056, RFC5929= ]=20 support). However, unless its use is mandatory for all client-authenticated= =20 connections, all the issues would still need to be dealt with.
=A0
Conclusion
=A0
I've tried to list all the issues I can think of with the HTTP=20 authentication framework as currently specified.=A0 Comments and additions= =20 are welcome.
=A0
=A0
=A0
=A0
=A0

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth




--
Website:= http://hallambaker.com/

--bcaec54a3e02f9db8c04cd64f5d3-- From pauljleach@msn.com Wed Oct 31 18:58:17 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 F148821F8540 for ; Wed, 31 Oct 2012 18:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_20=-0.74, HTML_MESSAGE=0.001] 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 M7MwNchK6S59 for ; Wed, 31 Oct 2012 18:58:17 -0700 (PDT) Received: from snt0-omc3-s42.snt0.hotmail.com (snt0-omc3-s42.snt0.hotmail.com [65.54.51.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35A21F853D for ; Wed, 31 Oct 2012 18:58:17 -0700 (PDT) Received: from SNT144-DS11 ([65.55.90.137]) by snt0-omc3-s42.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 18:58:16 -0700 X-Originating-IP: [70.19.82.236] X-EIP: [yHwad61dmbvmDHmVTbuPBtmlgeAqqOjI] X-Originating-Email: [pauljleach@msn.com] Message-ID: From: "Paul Leach" To: "Phillip Hallam-Baker" References: In-Reply-To: Date: Wed, 31 Oct 2012 21:58:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01CDB7B2.D307D520" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 01 Nov 2012 01:58:16.0893 (UTC) FILETIME=[5C0D2ED0:01CDB7D4] Cc: http-auth@ietf.org Subject: Re: [http-auth] My list of issues to be tackled in http auth framework 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, 01 Nov 2012 01:58:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01CDB7B2.D307D520 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Phil: Maybe I should have been more abstract about =E2=80=9Cchunked=E2=80=9D. = The problem isn=E2=80=99t per-chunk authentication per-se; it=E2=80=99s = that for big and indefinite length entity-bodies some form of = incremental authentication of entity-bodies is needed. I agree that my list assumed that account registration (which I have = more commonly seen referred to as =E2=80=9Cprovisioning=E2=80=9D) had = already happened, and that it omits consideration of collecting = credentials from the user. One could say that my list just deals with = what your draft calls =E2=80=9Cmessage authentication=E2=80=9D, which, = as you point out, is the only thing directly in the purview of HTTP. ------=_NextPart_000_00AB_01CDB7B2.D307D520 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Phil:
 
Maybe I should have been more abstract about = =E2=80=9Cchunked=E2=80=9D. The problem isn=E2=80=99t=20 per-chunk authentication per-se; it=E2=80=99s that for big and = indefinite length=20 entity-bodies some form of incremental authentication of entity-bodies = is=20 needed.
 
I agree that my list assumed that account registration (which I = have more=20 commonly seen referred to as =E2=80=9Cprovisioning=E2=80=9D) had already = happened, and that it=20 omits consideration of collecting credentials from the user. One could = say that=20 my list just deals with what your draft calls =E2=80=9Cmessage = authentication=E2=80=9D, which,=20 as you point out, is the only thing directly in the purview of = HTTP.
------=_NextPart_000_00AB_01CDB7B2.D307D520-- From hallam@gmail.com Wed Oct 31 19:15:58 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 26CD721F87EB for ; Wed, 31 Oct 2012 19:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 daXrOs0ZT-Ef for ; Wed, 31 Oct 2012 19:15:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF321F87D4 for ; Wed, 31 Oct 2012 19:15:56 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2268596obq.31 for ; Wed, 31 Oct 2012 19:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DY6K5VCYOezQJ7gbe504OFKxDC53yooq1+dPOJTOu00=; b=urs0yEFT5CEULo90EgqJR5lgBjcDya14RVaafxAamAnWqRHfUwECyL3KxlxXywIJ4y dr2ZIjY5FSINj1vb5M5uvu4PAeTDA2D6WqKDYbGni/uYcnrqkONBVUldcHMMZVJhEjKN QhYwc53nOV7feq0li/Zfd5vU7NPSEqqTgYXCEzYoKYvDDPuUEYt9JhGrxlVBwBRSfIz5 WU0LNfUpS7LMqv3xLMnrCzTVwpBMxb1qGw5XbWeOy8LbqwXxKKIHHIyCL66XKz0uDcpg 9+2TnLTVeOaAb9Nuo3n2IbbRA+Jk7Y9SC244HHteKMCKMDLIEaVqEKyhCTEW22w4KZWN WDEQ== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr32123349oec.36.1351736155780; Wed, 31 Oct 2012 19:15:55 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 31 Oct 2012 19:15:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Oct 2012 22:15:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Leach Content-Type: multipart/alternative; boundary=bcaec54a3e026535da04cd659918 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] My list of issues to be tackled in http auth framework 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, 01 Nov 2012 02:15:58 -0000 --bcaec54a3e026535da04cd659918 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think that at this point with HTTP 2.0 in discussion, well we should really revisit chunked. I would like HTTP/2.0 to replace the ASCII framing with binary and handle things like authentication and chunked properly in that context. Since we already have SSL in the mix it would make good sense for the HTTP framing to follow the SSL approach which is pretty easy to follow (well I think so). Some of the stuff we talked about at great length in HTTP-NG now seems to me to be just silly. Like all the concern about allowing for word alignment. While that might have been an issue in theory if the transport really was a stream of octets, it is actually sliced up into packets. And the sender can control the slices. So if quadword alignment was a real issue it would be something the TCP/IP stack could address as an optimization. [Appols if I seem to dredge up old history but I have had to dredge through rather a lot recently.] On Wed, Oct 31, 2012 at 9:58 PM, Paul Leach wrote: > Phil: > > Maybe I should have been more abstract about =93chunked=94. The problem i= sn=92t > per-chunk authentication per-se; it=92s that for big and indefinite lengt= h > entity-bodies some form of incremental authentication of entity-bodies is > needed. > > I agree that my list assumed that account registration (which I have more > commonly seen referred to as =93provisioning=94) had already happened, an= d that > it omits consideration of collecting credentials from the user. One could > say that my list just deals with what your draft calls =93message > authentication=94, which, as you point out, is the only thing directly in= the > purview of HTTP. > --=20 Website: http://hallambaker.com/ --bcaec54a3e026535da04cd659918 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think that at this point with HTTP 2.0 in discussion, well we should real= ly revisit chunked.=A0

I would like HTTP/2.0 to replace = the ASCII framing with binary and handle things like authentication and chu= nked properly in =A0that context.

Since we already have SSL in the mix it would make good= sense for the HTTP framing to follow the SSL approach which is =A0pretty e= asy to follow (well I think so).=A0

Some of the st= uff we talked about at great length in HTTP-NG now seems to me to be just s= illy. Like all the concern about allowing for word alignment. While that mi= ght have been an issue in theory if the transport really was a stream of oc= tets, it is actually sliced up into packets. And the sender can control the= slices. So if quadword alignment was a real issue it would be something th= e TCP/IP stack could address as an optimization.

[Appols if I seem to dredge up old history but I have h= ad to dredge through rather a lot recently.]



On Wed, Oct 31, 2012 at= 9:58 PM, Paul Leach <pauljleach@msn.com> wrote:
Phil:
=A0
Maybe I should have been more abstract about =93chunked=94. The proble= m isn=92t=20 per-chunk authentication per-se; it=92s that for big and indefinite length= =20 entity-bodies some form of incremental authentication of entity-bodies is= =20 needed.
=A0
I agree that my list assumed that account registration (which I have m= ore=20 commonly seen referred to as =93provisioning=94) had already happened, and = that it=20 omits consideration of collecting credentials from the user. One could say = that=20 my list just deals with what your draft calls =93message authentication=94,= which,=20 as you point out, is the only thing directly in the purview of HTTP.



--
Website: http://hallambaker.com/

--bcaec54a3e026535da04cd659918--