From dmaciejak@fortinet.com Sat Sep 1 09:43:42 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 79CBC21F866D for ; Sat, 1 Sep 2012 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJNIKz+x0R+F for ; Sat, 1 Sep 2012 09:43:41 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) by ietfa.amsl.com (Postfix) with ESMTP id DDFF821F866E for ; Sat, 1 Sep 2012 09:43:40 -0700 (PDT) Date: Sat, 1 Sep 2012 09:43:37 -0700 To: http-auth@ietf.org From: David Maciejak Message-ID: X-Priority: 3 X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.1] X-Mailer: FeLaMiMail In-Reply-To: <6369CB70BFD88942B9705AC1E639A338232A2BB0E3@DC-US1MBEX4.global.avaya.com> Organization: Fortinet Technologies Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_b5ada6d2ac6d5bdfe158fa7cad62b04b" Cc: "Ahrens, David \(David\)" Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Update 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, 01 Sep 2012 16:43:42 -0000 --b1_b5ada6d2ac6d5bdfe158fa7cad62b04b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----------------original message----------------- From: "Shekh-Yusef, Rifaat (Rifaat)" rifatyu@avaya.com To: "David Maciejak" dmaciejak@fortinet.com CC: "Ahrens, David (David)" davidahrens@avaya.com Date: Fri, 31 Aug 2012 14:31:36 -0400 ---------------------------------------------------------- Hi David, Can please raise this on the http-auth mailing list, as this discussion might be of interest to others? Sure. How would you envision it to work if you want to use qop, keeping in mind= the backward compatibility issue? I mean using "algorithm" as "qop" is used when passing multiple values eg= algorithm=3D"MD5, SHA1" if MD5 is the preferred algo. But this will break backward compatibility... Btw, were you able to do some tests about the multiple WWW-Authenticate headers ? In page 4 you wrote "The server MAY include multiple WWW-Authenticate headers", i believe you should define the separator used in this case, from your example seems to be a double CRLF ? I wonder if there is no bor= der line effect. best regards, david From: David Maciejak [mailto:dmaciejak@fortinet.com] Sent: Friday, August 31, 2012 10:59 AM To: Shekh-Yusef, Rifaat (Rifaat) Cc: Ahrens, David (David) Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Upda= te On 08/31/2012 04:39 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: Hi David, Thanks for your feedback. > You mean 2 WWW-Authenticate: Digest are sent to let the client choose t= he algo ? Yes, the idea is to allow servers to still be able to interact with clien= ts that only support the MD5 algorithm. yes i realized afterward you did this for older compatibility. I thought it should have been cleaner to do it like the qop value (eg qop=3D"auth, auth-int") ordered by preferred algo values. regards, david It is up to the server to decide on the level to security that it wish to= put on any document, and it might decide to only send one header with the= most secured algorithm. From: David Maciejak [[mailto:dmaciejak@fortinet.com] Sent: Friday, August 31, 2012 10:17 AM To: Shekh-Yusef, Rifaat (Rifaat) Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Upda= te On 08/31/2012 03:46 PM, Shekh-Yusef, Rifaat (Rifaat) wrote: Hello, The Digest mechanism, widely used in SIP networks, is based on the HTTP Digest mechanism defined in RFC 2617. The HTTP Digest mechanism states that MD5 is the algorithm to be used, an= d while it allows other algorithms to be added (per the 'token' defined in Section 3.2.1, algorithm =3D "algorithm" "=3D" ( "MD5" | "MD5-sess" | tok= en )), no other algorithm is specified. In 2008 the US-CERT issued a note that MD5 "should be considered cryptographically broken and unsuitable for further use". The following draft is an attempt to specify extensions to the HTTP Digest Access Authentication scheme by adding support for the SHA1 and SHA2 suite of ha= sh algorithms. https://datatracker.ietf.org/doc/draft-ahrens-httpbis-digest-auth-update/= ?include_text=3D1 Our initial goal was to address the issue for SIP, but when we discussed this topic offline with Mark Nottingham (HTTPbis chair) and Tobias Gondro= m (WebSec co-chair), they suggested to us to submit it in the context of HTTPbis to allow the group to consider HTTP Digest as one of the mechanis= ms for HTTP 2.0. We would really appreciate it if people can review the draft and provide = us with their feedback on the following: 1. The basic idea of extending RFC2617 to support other algorithms. 2. Including the extended HTTP Digest mechanism in HTTP 2.0. Regards, Rifaat _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth -> mailto:dmaciejak@fortinet.com] Hi Rifaat, yes i believe it's a good idea to update this old rfc with some other has= h algos. Moreover, on page 6-7 i am not sure about the example you put. You mean 2 WWW-Authenticate: Digest are sent to let the client choose the= algo ? thanks, david -- David Maciejak Sr. Security Researcher Fortinet - The New Generation of Secure Gateways 120 rue Albert Caquot | 06560, Sophia Antipolis | France PGP Key ID: A30A77ED This message is intended only for the personal and confidential use of th= e designated recipient(s) named above. If you are not the intended recipien= t of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended on= ly for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachment= s is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments= and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are= those of the individual sender and do not necessarily reflect the views o= f Fortinet, Inc., its affiliates, and emails are not binding on Fortinet an= d only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank= you. *** -- David Maciejak Sr. Security Researcher Fortinet - The New Generation of Secure Gateways 120 rue Albert Caquot | 06560, Sophia Antipolis | France PGP Key ID: A30A77ED This message is intended only for the personal and confidential use of th= e designated recipient(s) named above. If you are not the intended recipien= t of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended on= ly for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachment= s is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments= and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are= those of the individual sender and do not necessarily reflect the views o= f Fortinet, Inc., its affiliates, and emails are not binding on Fortinet an= d only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank= you. *** *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --b1_b5ada6d2ac6d5bdfe158fa7cad62b04b Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable


 

----------------original message-----------------
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: "David Maciejak" <dmaciejak@fortinet.com>
CC: "Ahrens, David (David)" <davidahrens@avaya.com>
Date: Fri, 31 Aug 2012 14:31:36 -0400
----------------------------------------------------------


Hi David,

 

Can please raise this on the http-auth = mailing list, as this discussion might be of interest to others?

Sure.

How would you envision it to work if yo= u want to use qop, keeping in mind the backward compatibility issue?

I mean using "algorithm" as "q= op" is used when passing multiple values eg algorithm=3D"MD5, SHA1" if MD5 is the preferred algo.

But this will break backward compatibility...

Btw, were you able to do some tests about the multiple WWW-Authenticate headers ?

In page 4 you wrote "The server MAY include multiple WWW-Authenticate headers= ", i believe you should define the separator used in this case,

from your example seems to be a double CRLF ? I wonde= r if there is no border line effect.

 

best regards,

david

 

 

Fr= om: David Maciejak [mailto:dmaciejak@fortinet.com]
Sent: Friday, August 31, 2012 10:59 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Ahrens, David (David)
Subject: Re: [http-auth] HTTP Digest Access Authentication Algorit= hm Update

 

On 08/31/2012 04:39 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi David,

 

Thanks for your feedback.

 

> You mean 2  WWW-Authenticate: = Digest are sent to let the client choose the algo ?

Yes, the idea is to allow servers to st= ill be able to interact with clients that only support the MD5 algorithm.=

y= es i realized afterward you did this for older compatibility.
I thought it should have been cleaner to do it like the qop value (eg= 0; qop=3D"auth, auth-int") ordered by preferred algo values.


regards,
david


It is up to the server to decide on the= level to security that it wish to put on any document, and it might deci= de to only send one header with the most secured algorithm.

 

 

Fr= om: David Maciejak [mailto:d= maciejak@fortinet.com]
Sent: Friday, August 31, 2012 10:17 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Subject: Re: [http-auth] HTTP Digest Access Authentication Algorit= hm Update

 

On 08/31/2012 03:46 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hello,

 

The Digest mechanism, widely used in SIP networks, is based on the HTT= P Digest mechanism defined in RFC 2617.

The HTTP Digest mechanism states that MD5 is the algorithm to be used,= and while it allows other algorithms to be added (per the 'token' define= d in Section 3.2.1, algorithm =3D "algorithm" "=3D" ( "MD5" | "MD5-sess" = | token )), no other algorithm is specified.

 

In 2008 the US-CERT issued a note that MD5 "should be considered crypt= ographically broken and unsuitable for further use". The following draft = is an attempt to specify extensions to the HTTP Digest Access Authenticat= ion scheme by adding support for the SHA1 and SHA2 suite of hash algorith= ms.

 

https://datatracker.ietf.org/doc/draft-a= hrens-httpbis-digest-auth-update/?include_text=3D1

 

 

Our initial goal was to address the issue for SIP, but when we discuss= ed this topic offline with Mark Nottingham (HTTPbis chair) and Tobias Gon= drom (WebSec co-chair), they suggested to us to submit it in the context = of HTTPbis to allow the group to consider HTTP Digest as one of the mecha= nisms for HTTP 2.0.

 

We would really appreciate it if people can review the draft and provi= de us with their feedback on the following:

1. The basic idea of extending RFC2617 to support other algorithms.

2. Including the extended HTTP Digest mechanism in HTTP 2.0.

 

Regards,

Rifaat

 





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


Hi Rifaat,

yes i believe it's a good idea to update this old rfc with some other has= h algos.
Moreover, on page 6-7 i am not sure about the example you put.
You mean 2  WWW-Authenticate: Digest are sent to let the client choo= se the algo ?

thanks,
david



--

David Maciejak
Sr. Security Researcher
Fortinet - The New Generation of Secure Gateways
120 rue Albert Caquot | 06560, Sophia Antipolis | France
PGP Key ID: A30A77ED

This message is intended only for the personal and confidential = use of the designated recipient(s) named above. If you are not the intend= ed recipient of this message you are hereby notified that any review, dis= semination, distribution or copying of this message is strictly prohibite= d.

&#= 160;

 

**= * Please note that this message and any attachments may contain confident= ial and proprietary material and information and are intended only for th= e use of the intended recipient(s). If you are not the intended recipient= , you are hereby notified that any review, use, disclosure, dissemination= , distribution or copying of this message and any attachments is strictly= prohibited. If you have received this email in error, please immediately= notify the sender and destroy this e-mail and any attachments and all co= pies, whether electronic or printed. Please also note that any views, opi= nions, conclusions or commitments expressed in this message are those of = the individual sender and do not necessarily reflect the views of Fortine= t, Inc., its affiliates, and emails are not binding on Fortinet and only = a writing manually signed by Fortinet's General Counsel can be a binding = commitment of Fortinet to Fortinet's customers or partners. Thank you. **= *

 

&= #160;

-= -

David Maciejak
Sr. Security Researcher
Fortinet - The New Generation of Secure Gateways
120 rue Albert Caquot | 06560, Sophia Antipolis | France
PGP Key ID: A30A77ED

This message is intended only for the personal and confidential = use of the designated recipient(s) named above. If you are not the intend= ed recipient of this message you are hereby notified that any review, dis= semination, distribution or copying of this message is strictly prohibite= d.

 

 

 


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--b1_b5ada6d2ac6d5bdfe158fa7cad62b04b-- From rifatyu@avaya.com Sun Sep 2 18:49:01 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 9439321F8471 for ; Sun, 2 Sep 2012 18:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 ssY0ueEqNvmz for ; Sun, 2 Sep 2012 18:49:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6777321F8476 for ; Sun, 2 Sep 2012 18:48:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALQLRFDGmAcF/2dsb2JhbABFgkqDO7Qnc4EHgiABAQEBAgEBAQEPEQpBAwgFCwIBBgINAQMDAQEBIQcDAgICJQsUCQgBAQQBDQUIGodlBgudZ4oekXgEiw0ahXcyYAObWooZgn+BRQ X-IronPort-AV: E=Sophos;i="4.80,357,1344225600"; d="scan'208,217";a="365269110" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Sep 2012 21:44:05 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2012 21:42:37 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.193]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Sun, 2 Sep 2012 21:48:55 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: David Maciejak , "http-auth@ietf.org" Date: Sun, 2 Sep 2012 21:48:53 -0400 Thread-Topic: [http-auth] HTTP Digest Access Authentication Algorithm Update Thread-Index: Ac2IYPP1gbONwGaeRMizzQKDFZGXOwBEkoHg Message-ID: <6369CB70BFD88942B9705AC1E639A338232A2BB2EB@DC-US1MBEX4.global.avaya.com> References: <6369CB70BFD88942B9705AC1E639A338232A2BB0E3@DC-US1MBEX4.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A338232A2BB2EBDCUS1MBEX4glo_" MIME-Version: 1.0 Cc: "Ahrens, David \(David\)" Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 01:49:01 -0000 --_000_6369CB70BFD88942B9705AC1E639A338232A2BB2EBDCUS1MBEX4glo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCg0KPiBJIG1lYW4gdXNpbmcgImFsZ29yaXRobSIgYXMgInFvcCIgaXMgdXNl ZCB3aGVuIHBhc3NpbmcgbXVsdGlwbGUgdmFsdWVzIGVnIGFsZ29yaXRobT0iTUQ1LCBTSEExIiBp ZiBNRDUgaXMgdGhlIHByZWZlcnJlZCBhbGdvLg0KDQo+IEJ1dCB0aGlzIHdpbGwgYnJlYWsgYmFj a3dhcmQgY29tcGF0aWJpbGl0eS4uLg0KDQpZZWFoLCB0aGlzIHdpbGwgYnJlYWsgdGhlIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHksIGFzIHRoZSBSRkMyNjE3IGRlZmluZXMgdGhlIGFsZ29yaXRobSBw YXJhbWV0ZXIgdG8gYmUgYSDigJzigKYgYSBwYWlyIG9mIGFsZ29yaXRobXPigKbigJ0uDQoNCg0K DQo+IEJ0dywgd2VyZSB5b3UgYWJsZSB0byBkbyBzb21lIHRlc3RzIGFib3V0IHRoZSBtdWx0aXBs ZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlcnMgPw0KDQpOb3QgeWV0Lg0KDQoNCg0KPiBJbiBwYWdl IDQgeW91IHdyb3RlICJUaGUgc2VydmVyIE1BWSBpbmNsdWRlIG11bHRpcGxlIFdXVy1BdXRoZW50 aWNhdGUgaGVhZGVycyIsIGkgYmVsaWV2ZSB5b3Ugc2hvdWxkIGRlZmluZSB0aGUgc2VwYXJhdG9y IHVzZWQgaW4gdGhpcyBjYXNlLA0KDQpUaGVzZSBhcmUgdHdvIGhlYWRlcnMgaW4gYSA0MDEgcmVz cG9uc2UsIGFuZCB0aGUgZXh0cmEgQ1JMRiBzaG91bGQgbm90IGJlIHRoZXJlLiBXZSB3aWxsIGZp eCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KDQoNClJlZ2FyZHMsDQoN ClJpZmFhdA0KDQoNCg0KDQoNCkZyb206IERhdmlkIE1hY2llamFrIFttYWlsdG86ZG1hY2llamFr QGZvcnRpbmV0LmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTIgMTI6NDQg UE0NClRvOiBodHRwLWF1dGhAaWV0Zi5vcmcNCkNjOiBTaGVraC1ZdXNlZiwgUmlmYWF0IChSaWZh YXQpOyBBaHJlbnMsIERhdmlkIChEYXZpZCkNClN1YmplY3Q6IFJFOiBbaHR0cC1hdXRoXSBIVFRQ IERpZ2VzdCBBY2Nlc3MgQXV0aGVudGljYXRpb24gQWxnb3JpdGhtIFVwZGF0ZQ0KDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tb3JpZ2luYWwgbWVzc2FnZS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAi U2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0KSIgPHJpZmF0eXVAYXZheWEuY29tPg0KVG86ICJE YXZpZCBNYWNpZWphayIgPGRtYWNpZWpha0Bmb3J0aW5ldC5jb20+DQpDQzogIkFocmVucywgRGF2 aWQgKERhdmlkKSIgPGRhdmlkYWhyZW5zQGF2YXlhLmNvbT4NCkRhdGU6IEZyaSwgMzEgQXVnIDIw MTIgMTQ6MzE6MzYgLTA0MDANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpIaSBEYXZpZCwNCg0KDQoNCkNhbiBwbGVhc2UgcmFp c2UgdGhpcyBvbiB0aGUgaHR0cC1hdXRoIG1haWxpbmcgbGlzdCwgYXMgdGhpcyBkaXNjdXNzaW9u IG1pZ2h0IGJlIG9mIGludGVyZXN0IHRvIG90aGVycz8NCg0KU3VyZS4NCg0KSG93IHdvdWxkIHlv dSBlbnZpc2lvbiBpdCB0byB3b3JrIGlmIHlvdSB3YW50IHRvIHVzZSBxb3AsIGtlZXBpbmcgaW4g bWluZCB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZT8NCg0KSSBtZWFuIHVzaW5nICJh bGdvcml0aG0iIGFzICJxb3AiIGlzIHVzZWQgd2hlbiBwYXNzaW5nIG11bHRpcGxlIHZhbHVlcyBl ZyBhbGdvcml0aG09Ik1ENSwgU0hBMSIgaWYgTUQ1IGlzIHRoZSBwcmVmZXJyZWQgYWxnby4NCg0K QnV0IHRoaXMgd2lsbCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Li4uDQoNCkJ0dywgd2Vy ZSB5b3UgYWJsZSB0byBkbyBzb21lIHRlc3RzIGFib3V0IHRoZSBtdWx0aXBsZSBXV1ctQXV0aGVu dGljYXRlIGhlYWRlcnMgPw0KDQpJbiBwYWdlIDQgeW91IHdyb3RlICJUaGUgc2VydmVyIE1BWSBp bmNsdWRlIG11bHRpcGxlIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVycyIsIGkgYmVsaWV2ZSB5b3Ug c2hvdWxkIGRlZmluZSB0aGUgc2VwYXJhdG9yIHVzZWQgaW4gdGhpcyBjYXNlLA0KDQpmcm9tIHlv dXIgZXhhbXBsZSBzZWVtcyB0byBiZSBhIGRvdWJsZSBDUkxGID8gSSB3b25kZXIgaWYgdGhlcmUg aXMgbm8gYm9yZGVyIGxpbmUgZWZmZWN0Lg0KDQoNCg0KYmVzdCByZWdhcmRzLA0KDQpkYXZpZA0K DQoNCg0KDQoNCkZyb206IERhdmlkIE1hY2llamFrIFttYWlsdG86ZG1hY2llamFrQGZvcnRpbmV0 LmNvbV0NClNlbnQ6IEZyaWRheSwgQXVndXN0IDMxLCAyMDEyIDEwOjU5IEFNDQpUbzogU2hla2gt WXVzZWYsIFJpZmFhdCAoUmlmYWF0KQ0KQ2M6IEFocmVucywgRGF2aWQgKERhdmlkKQ0KU3ViamVj dDogUmU6IFtodHRwLWF1dGhdIEhUVFAgRGlnZXN0IEFjY2VzcyBBdXRoZW50aWNhdGlvbiBBbGdv cml0aG0gVXBkYXRlDQoNCg0KDQpPbiAwOC8zMS8yMDEyIDA0OjM5IFBNLCBTaGVraC1ZdXNlZiwg UmlmYWF0IChSaWZhYXQpIHdyb3RlOg0KDQpIaSBEYXZpZCwNCg0KDQoNClRoYW5rcyBmb3IgeW91 ciBmZWVkYmFjay4NCg0KDQoNCj4gWW91IG1lYW4gMiAgV1dXLUF1dGhlbnRpY2F0ZTogRGlnZXN0 IGFyZSBzZW50IHRvIGxldCB0aGUgY2xpZW50IGNob29zZSB0aGUgYWxnbyA/DQoNClllcywgdGhl IGlkZWEgaXMgdG8gYWxsb3cgc2VydmVycyB0byBzdGlsbCBiZSBhYmxlIHRvIGludGVyYWN0IHdp dGggY2xpZW50cyB0aGF0IG9ubHkgc3VwcG9ydCB0aGUgTUQ1IGFsZ29yaXRobS4NCg0KeWVzIGkg cmVhbGl6ZWQgYWZ0ZXJ3YXJkIHlvdSBkaWQgdGhpcyBmb3Igb2xkZXIgY29tcGF0aWJpbGl0eS4N CkkgdGhvdWdodCBpdCBzaG91bGQgaGF2ZSBiZWVuIGNsZWFuZXIgdG8gZG8gaXQgbGlrZSB0aGUg cW9wIHZhbHVlIChlZyAgcW9wPSJhdXRoLCBhdXRoLWludCIpIG9yZGVyZWQgYnkgcHJlZmVycmVk IGFsZ28gdmFsdWVzLg0KDQoNCnJlZ2FyZHMsDQpkYXZpZA0KDQoNCkl0IGlzIHVwIHRvIHRoZSBz ZXJ2ZXIgdG8gZGVjaWRlIG9uIHRoZSBsZXZlbCB0byBzZWN1cml0eSB0aGF0IGl0IHdpc2ggdG8g cHV0IG9uIGFueSBkb2N1bWVudCwgYW5kIGl0IG1pZ2h0IGRlY2lkZSB0byBvbmx5IHNlbmQgb25l IGhlYWRlciB3aXRoIHRoZSBtb3N0IHNlY3VyZWQgYWxnb3JpdGhtLg0KDQoNCg0KDQoNCkZyb206 IERhdmlkIE1hY2llamFrIFttYWlsdG86ZG1hY2llamFrQGZvcnRpbmV0LmNvbV0NClNlbnQ6IEZy aWRheSwgQXVndXN0IDMxLCAyMDEyIDEwOjE3IEFNDQpUbzogU2hla2gtWXVzZWYsIFJpZmFhdCAo UmlmYWF0KQ0KU3ViamVjdDogUmU6IFtodHRwLWF1dGhdIEhUVFAgRGlnZXN0IEFjY2VzcyBBdXRo ZW50aWNhdGlvbiBBbGdvcml0aG0gVXBkYXRlDQoNCg0KDQpPbiAwOC8zMS8yMDEyIDAzOjQ2IFBN LCBTaGVraC1ZdXNlZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOg0KDQpIZWxsbywNCg0KDQoNClRo ZSBEaWdlc3QgbWVjaGFuaXNtLCB3aWRlbHkgdXNlZCBpbiBTSVAgbmV0d29ya3MsIGlzIGJhc2Vk IG9uIHRoZSBIVFRQIERpZ2VzdCBtZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMgMjYxNy4NCg0KVGhl IEhUVFAgRGlnZXN0IG1lY2hhbmlzbSBzdGF0ZXMgdGhhdCBNRDUgaXMgdGhlIGFsZ29yaXRobSB0 byBiZSB1c2VkLCBhbmQgd2hpbGUgaXQgYWxsb3dzIG90aGVyIGFsZ29yaXRobXMgdG8gYmUgYWRk ZWQgKHBlciB0aGUgJ3Rva2VuJyBkZWZpbmVkIGluIFNlY3Rpb24gMy4yLjEsIGFsZ29yaXRobSA9 ICJhbGdvcml0aG0iICI9IiAoICJNRDUiIHwgIk1ENS1zZXNzIiB8IHRva2VuICkpLCBubyBvdGhl ciBhbGdvcml0aG0gaXMgc3BlY2lmaWVkLg0KDQoNCg0KSW4gMjAwOCB0aGUgVVMtQ0VSVCBpc3N1 ZWQgYSBub3RlIHRoYXQgTUQ1ICJzaG91bGQgYmUgY29uc2lkZXJlZCBjcnlwdG9ncmFwaGljYWxs eSBicm9rZW4gYW5kIHVuc3VpdGFibGUgZm9yIGZ1cnRoZXIgdXNlIi4gVGhlIGZvbGxvd2luZyBk cmFmdCBpcyBhbiBhdHRlbXB0IHRvIHNwZWNpZnkgZXh0ZW5zaW9ucyB0byB0aGUgSFRUUCBEaWdl c3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIHNjaGVtZSBieSBhZGRpbmcgc3VwcG9ydCBmb3IgdGhl IFNIQTEgYW5kIFNIQTIgc3VpdGUgb2YgaGFzaCBhbGdvcml0aG1zLg0KDQoNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWhyZW5zLWh0dHBiaXMtZGlnZXN0LWF1dGgt dXBkYXRlLz9pbmNsdWRlX3RleHQ9MQ0KDQoNCg0KDQoNCk91ciBpbml0aWFsIGdvYWwgd2FzIHRv IGFkZHJlc3MgdGhlIGlzc3VlIGZvciBTSVAsIGJ1dCB3aGVuIHdlIGRpc2N1c3NlZCB0aGlzIHRv cGljIG9mZmxpbmUgd2l0aCBNYXJrIE5vdHRpbmdoYW0gKEhUVFBiaXMgY2hhaXIpIGFuZCBUb2Jp YXMgR29uZHJvbSAoV2ViU2VjIGNvLWNoYWlyKSwgdGhleSBzdWdnZXN0ZWQgdG8gdXMgdG8gc3Vi bWl0IGl0IGluIHRoZSBjb250ZXh0IG9mIEhUVFBiaXMgdG8gYWxsb3cgdGhlIGdyb3VwIHRvIGNv bnNpZGVyIEhUVFAgRGlnZXN0IGFzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyBmb3IgSFRUUCAyLjAu DQoNCg0KDQpXZSB3b3VsZCByZWFsbHkgYXBwcmVjaWF0ZSBpdCBpZiBwZW9wbGUgY2FuIHJldmll dyB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgdXMgd2l0aCB0aGVpciBmZWVkYmFjayBvbiB0aGUgZm9s bG93aW5nOg0KDQoxLiBUaGUgYmFzaWMgaWRlYSBvZiBleHRlbmRpbmcgUkZDMjYxNyB0byBzdXBw b3J0IG90aGVyIGFsZ29yaXRobXMuDQoNCjIuIEluY2x1ZGluZyB0aGUgZXh0ZW5kZWQgSFRUUCBE aWdlc3QgbWVjaGFuaXNtIGluIEhUVFAgMi4wLg0KDQoNCg0KUmVnYXJkcywNCg0KUmlmYWF0DQoN Cg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KDQoNCmh0dHAtYXV0aCBtYWlsaW5nIGxpc3QNCg0KaHR0cC1hdXRoQGlldGYub3Jn PG1haWx0bzpodHRwLWF1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaHR0cC1hdXRoDQoNCkhpIFJpZmFhdCwNCg0KeWVzIGkgYmVsaWV2ZSBpdCdz IGEgZ29vZCBpZGVhIHRvIHVwZGF0ZSB0aGlzIG9sZCByZmMgd2l0aCBzb21lIG90aGVyIGhhc2gg YWxnb3MuDQpNb3Jlb3Zlciwgb24gcGFnZSA2LTcgaSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZXhh bXBsZSB5b3UgcHV0Lg0KWW91IG1lYW4gMiAgV1dXLUF1dGhlbnRpY2F0ZTogRGlnZXN0IGFyZSBz ZW50IHRvIGxldCB0aGUgY2xpZW50IGNob29zZSB0aGUgYWxnbyA/DQoNCnRoYW5rcywNCmRhdmlk DQoNCg0KDQotLQ0KDQpEYXZpZCBNYWNpZWphaw0KU3IuIFNlY3VyaXR5IFJlc2VhcmNoZXINCkZv cnRpbmV0IC0gVGhlIE5ldyBHZW5lcmF0aW9uIG9mIFNlY3VyZSBHYXRld2F5cw0KMTIwIHJ1ZSBB bGJlcnQgQ2FxdW90IHwgMDY1NjAsIFNvcGhpYSBBbnRpcG9saXMgfCBGcmFuY2UNClBHUCBLZXkg SUQ6IEEzMEE3N0VEDQoNClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uYWwgYW5kIGNvbmZpZGVudGlhbCB1c2Ugb2YgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50KHMp IG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo aXMgbWVzc2FnZSB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXZpZXcsIGRpc3Nl bWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLg0KDQoNCg0KDQoqKiogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3By aWV0YXJ5IG1hdGVyaWFsIGFuZCBpbmZvcm1hdGlvbiBhbmQgYXJlIGludGVuZGVkIG9ubHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmV2 aWV3LCB1c2UsIGRpc2Nsb3N1cmUsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVzdHJveSB0aGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhbGwgY29waWVzLCB3aGV0aGVyIGVsZWN0cm9uaWMgb3IgcHJp bnRlZC4gUGxlYXNlIGFsc28gbm90ZSB0aGF0IGFueSB2aWV3cywgb3BpbmlvbnMsIGNvbmNsdXNp b25zIG9yIGNvbW1pdG1lbnRzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgdGhl IHZpZXdzIG9mIEZvcnRpbmV0LCBJbmMuLCBpdHMgYWZmaWxpYXRlcywgYW5kIGVtYWlscyBhcmUg bm90IGJpbmRpbmcgb24gRm9ydGluZXQgYW5kIG9ubHkgYSB3cml0aW5nIG1hbnVhbGx5IHNpZ25l ZCBieSBGb3J0aW5ldCdzIEdlbmVyYWwgQ291bnNlbCBjYW4gYmUgYSBiaW5kaW5nIGNvbW1pdG1l bnQgb2YgRm9ydGluZXQgdG8gRm9ydGluZXQncyBjdXN0b21lcnMgb3IgcGFydG5lcnMuIFRoYW5r IHlvdS4gKioqDQoNCg0KDQoNCi0tDQoNCkRhdmlkIE1hY2llamFrDQpTci4gU2VjdXJpdHkgUmVz ZWFyY2hlcg0KRm9ydGluZXQgLSBUaGUgTmV3IEdlbmVyYXRpb24gb2YgU2VjdXJlIEdhdGV3YXlz DQoxMjAgcnVlIEFsYmVydCBDYXF1b3QgfCAwNjU2MCwgU29waGlhIEFudGlwb2xpcyB8IEZyYW5j ZQ0KUEdQIEtleSBJRDogQTMwQTc3RUQNCg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgZGVzaWduYXRlZCBy ZWNpcGllbnQocykgbmFtZWQgYWJvdmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgb2YgdGhpcyBtZXNzYWdlIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJl dmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNz YWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQoNCg0KDQoNCioqKiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJvcHJpZXRhcnkgbWF0ZXJpYWwgYW5kIGluZm9ybWF0aW9uIGFuZCBhcmUgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSByZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZXN0cm95IHRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFsbCBjb3BpZXMsIHdoZXRoZXIgZWxlY3Ry b25pYyBvciBwcmludGVkLiBQbGVhc2UgYWxzbyBub3RlIHRoYXQgYW55IHZpZXdzLCBvcGluaW9u cywgY29uY2x1c2lvbnMgb3IgY29tbWl0bWVudHMgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBh cmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkg cmVmbGVjdCB0aGUgdmlld3Mgb2YgRm9ydGluZXQsIEluYy4sIGl0cyBhZmZpbGlhdGVzLCBhbmQg ZW1haWxzIGFyZSBub3QgYmluZGluZyBvbiBGb3J0aW5ldCBhbmQgb25seSBhIHdyaXRpbmcgbWFu dWFsbHkgc2lnbmVkIGJ5IEZvcnRpbmV0J3MgR2VuZXJhbCBDb3Vuc2VsIGNhbiBiZSBhIGJpbmRp bmcgY29tbWl0bWVudCBvZiBGb3J0aW5ldCB0byBGb3J0aW5ldCdzIGN1c3RvbWVycyBvciBwYXJ0 bmVycy4gVGhhbmsgeW91LiAqKioNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCioqKiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgbWF0ZXJpYWwgYW5k IGluZm9ybWF0aW9uIGFuZCBhcmUgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXZpZXcsIHVzZSwgZGlzY2xvc3Vy ZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdl IGFuZCBhbnkgYXR0YWNobWVudHMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZXN0cm95IHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYW5k IGFsbCBjb3BpZXMsIHdoZXRoZXIgZWxlY3Ryb25pYyBvciBwcmludGVkLiBQbGVhc2UgYWxzbyBu b3RlIHRoYXQgYW55IHZpZXdzLCBvcGluaW9ucywgY29uY2x1c2lvbnMgb3IgY29tbWl0bWVudHMg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGUgdmlld3Mgb2YgRm9ydGluZXQs IEluYy4sIGl0cyBhZmZpbGlhdGVzLCBhbmQgZW1haWxzIGFyZSBub3QgYmluZGluZyBvbiBGb3J0 aW5ldCBhbmQgb25seSBhIHdyaXRpbmcgbWFudWFsbHkgc2lnbmVkIGJ5IEZvcnRpbmV0J3MgR2Vu ZXJhbCBDb3Vuc2VsIGNhbiBiZSBhIGJpbmRpbmcgY29tbWl0bWVudCBvZiBGb3J0aW5ldCB0byBG b3J0aW5ldCdzIGN1c3RvbWVycyBvciBwYXJ0bmVycy4gVGhhbmsgeW91LiAqKioNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo= --_000_6369CB70BFD88942B9705AC1E639A338232A2BB2EBDCUS1MBEX4glo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv bnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SGkgRGF2aWQsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBz dHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Jmd0Ozwvc3Bhbj4gSSBtZWFuIHVzaW5nICZxdW90O2FsZ29yaXRobSZxdW90OyBhcyAm cXVvdDtxb3AmcXVvdDsgaXMgdXNlZCB3aGVuIHBhc3NpbmcgbXVsdGlwbGUgdmFsdWVzIGVnIGFs Z29yaXRobT0mcXVvdDtNRDUsIFNIQTEmcXVvdDsgaWYgTUQ1IGlzIHRoZSBwcmVmZXJyZWQgYWxn by48bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQnPiZndDsgQnV0IHRoaXMgd2lsbCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Li4uPG86 cD48L286cD48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlllYWgsIHRoaXMgd2lsbCBicmVhayB0aGUgYmFja3dhcmQg Y29tcGF0aWJpbGl0eSwgYXMgdGhlIFJGQzI2MTcgZGVmaW5lcyB0aGUgYWxnb3JpdGhtIHBhcmFt ZXRlciB0byBiZSBhIOKAnOKApiBhIHBhaXIgb2YgYWxnb3JpdGhtc+KApuKAnS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBzdHls ZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+Jmd0Ozwvc3Bhbj4gQnR3LCB3ZXJlIHlvdSBhYmxlIHRvIGRvIHNvbWUgdGVzdHMgYWJvdXQg dGhlIG11bHRpcGxlJm5ic3A7PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPldXVy1BdXRo ZW50aWNhdGUgaGVhZGVycyA/PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ob3QgeWV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBz dHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7PC9zcGFuPiBJ biBwYWdlIDQgeW91IHdyb3RlICZxdW90OzxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5U aGUmbmJzcDs8L3NwYW4+c2VydmVyIE1BWSBpbmNsdWRlIG11bHRpcGxlIFdXVy1BdXRoZW50aWNh dGUgaGVhZGVycyZxdW90OywgaSBiZWxpZXZlIHlvdSBzaG91bGQgZGVmaW5lIHRoZSBzZXBhcmF0 b3IgdXNlZCBpbiB0aGlzIGNhc2UsPG86cD48L286cD48L3A+PHAgc3R5bGU9J21hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZXNlIGFyZSB0 d28gaGVhZGVycyBpbiBhIDQwMSByZXNwb25zZSwgYW5kIHRoZSBleHRyYSBDUkxGIHNob3VsZCBu b3QgYmUgdGhlcmUuIFdlIHdpbGwgZml4IGl0IGluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0n bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ IFJpZmFhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IERh dmlkIE1hY2llamFrIFttYWlsdG86ZG1hY2llamFrQGZvcnRpbmV0LmNvbV0gPGJyPjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgU2VwdGVtYmVyIDAxLCAyMDEyIDEyOjQ0IFBNPGJyPjxiPlRvOjwvYj4g aHR0cC1hdXRoQGlldGYub3JnPGJyPjxiPkNjOjwvYj4gU2hla2gtWXVzZWYsIFJpZmFhdCAoUmlm YWF0KTsgQWhyZW5zLCBEYXZpZCAoRGF2aWQpPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW2h0dHAt YXV0aF0gSFRUUCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSBVcGRhdGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwPjxicj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD4tLS0tLS0tLS0t LS0tLS0tb3JpZ2luYWwgbWVzc2FnZS0tLS0tLS0tLS0tLS0tLS0tPGJyPkZyb206ICZxdW90O1No ZWtoLVl1c2VmLCBSaWZhYXQgKFJpZmFhdCkmcXVvdDsgJmx0O3JpZmF0eXVAYXZheWEuY29tJmd0 Ozxicj5UbzogJnF1b3Q7RGF2aWQgTWFjaWVqYWsmcXVvdDsgJmx0O2RtYWNpZWpha0Bmb3J0aW5l dC5jb20mZ3Q7PGJyPkNDOiAmcXVvdDtBaHJlbnMsIERhdmlkIChEYXZpZCkmcXVvdDsgJmx0O2Rh dmlkYWhyZW5zQGF2YXlhLmNvbSZndDs8YnI+RGF0ZTogRnJpLCAzMSBBdWcgMjAxMiAxNDozMToz NiAtMDQwMDxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxkaXY+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhpIERhdmlkLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5DYW4g cGxlYXNlIHJhaXNlIHRoaXMgb24gdGhlIGh0dHAtYXV0aCBtYWlsaW5nIGxpc3QsIGFzIHRoaXMg ZGlzY3Vzc2lvbiBtaWdodCBiZSBvZiBpbnRlcmVzdCB0byBvdGhlcnM/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwPlN1cmUuPG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPkhvdyB3b3VsZCB5b3UgZW52aXNpb24gaXQgdG8gd29yayBpZiB5b3Ugd2FudCB0byB1c2Ug cW9wLCBrZWVwaW5nIGluIG1pbmQgdGhlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWU/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwPkkgbWVhbiB1c2luZyAmcXVvdDthbGdvcml0aG0mcXVvdDsg YXMgJnF1b3Q7cW9wJnF1b3Q7IGlzIHVzZWQgd2hlbiBwYXNzaW5nIG11bHRpcGxlIHZhbHVlcyBl ZyBhbGdvcml0aG09JnF1b3Q7TUQ1LCBTSEExJnF1b3Q7IGlmIE1ENSBpcyB0aGUgcHJlZmVycmVk IGFsZ28uPG86cD48L286cD48L3A+PHA+QnV0IHRoaXMgd2lsbCBicmVhayBiYWNrd2FyZCBjb21w YXRpYmlsaXR5Li4uPG86cD48L286cD48L3A+PHA+QnR3LCB3ZXJlIHlvdSBhYmxlIHRvIGRvIHNv bWUgdGVzdHMgYWJvdXQgdGhlIG11bHRpcGxlJm5ic3A7PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPldXVy1BdXRoZW50aWNhdGUgaGVhZGVycyA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PkluIHBhZ2UgNCB5b3Ugd3JvdGUgJnF1b3Q7PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PlRoZSZuYnNwOzwvc3Bhbj5zZXJ2ZXIgTUFZIGluY2x1ZGUgbXVsdGlwbGUgV1dXLUF1dGhlbnRp Y2F0ZSBoZWFkZXJzJnF1b3Q7LCBpIGJlbGlldmUgeW91IHNob3VsZCBkZWZpbmUgdGhlIHNlcGFy YXRvciB1c2VkIGluIHRoaXMgY2FzZSw8bzpwPjwvbzpwPjwvcD48cD5mcm9tIHlvdXIgZXhhbXBs ZSBzZWVtcyB0byBiZSBhIGRvdWJsZSBDUkxGID8mbmJzcDs8c3BhbiBzdHlsZT0nZm9udC1zaXpl OjkuNXB0Jz5JIHdvbmRlciBpZiB0aGVyZSBpcyBubyBib3JkZXIgbGluZSBlZmZlY3QuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwPmJlc3QgcmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD48cD5kYXZpZDxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2Nv bG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PGRpdj48 cD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBEYXZpZCBNYWNpZWphayBbbWFp bHRvOmRtYWNpZWpha0Bmb3J0aW5ldC5jb21dIDxicj48Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1 c3QgMzEsIDIwMTIgMTA6NTkgQU08YnI+PGI+VG86PC9iPiBTaGVraC1ZdXNlZiwgUmlmYWF0IChS aWZhYXQpPGJyPjxiPkNjOjwvYj4gQWhyZW5zLCBEYXZpZCAoRGF2aWQpPGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogW2h0dHAtYXV0aF0gSFRUUCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIEFs Z29yaXRobSBVcGRhdGU8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHA+Jm5ic3A7 PG86cD48L286cD48L3A+PGRpdj48cD5PbiAwOC8zMS8yMDEyIDA0OjM5IFBNLCBTaGVraC1ZdXNl ZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz5IaSBEYXZpZCw8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7PC9z cGFuPiBZb3UgbWVhbiAyJm5ic3A7IFdXVy1BdXRoZW50aWNhdGU6IERpZ2VzdCBhcmUgc2VudCB0 byBsZXQgdGhlIGNsaWVudCBjaG9vc2UgdGhlIGFsZ28gPzxvOnA+PC9vOnA+PC9wPjxwPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5ZZXMsIHRoZSBpZGVhIGlzIHRvIGFsbG93IHNlcnZlcnMg dG8gc3RpbGwgYmUgYWJsZSB0byBpbnRlcmFjdCB3aXRoIGNsaWVudHMgdGhhdCBvbmx5IHN1cHBv cnQgdGhlIE1ENSBhbGdvcml0aG0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48 cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPnllcyBpIHJlYWxpemVkIGFmdGVyd2FyZCB5 b3UgZGlkIHRoaXMgZm9yIG9sZGVyIGNvbXBhdGliaWxpdHkuPGJyPkkgdGhvdWdodCBpdCBzaG91 bGQgaGF2ZSBiZWVuIGNsZWFuZXIgdG8gZG8gaXQgbGlrZSB0aGUgcW9wIHZhbHVlIChlZyZuYnNw OyBxb3A9JnF1b3Q7YXV0aCwgYXV0aC1pbnQmcXVvdDspIG9yZGVyZWQgYnkgcHJlZmVycmVkIGFs Z28gdmFsdWVzLjxicj48YnI+PGJyPnJlZ2FyZHMsPGJyPmRhdmlkPGJyPjxicj48bzpwPjwvbzpw PjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXQgaXMgdXAgdG8gdGhlIHNlcnZl ciB0byBkZWNpZGUgb24gdGhlIGxldmVsIHRvIHNlY3VyaXR5IHRoYXQgaXQgd2lzaCB0byBwdXQg b24gYW55IGRvY3VtZW50LCBhbmQgaXQgbWlnaHQgZGVjaWRlIHRvIG9ubHkgc2VuZCBvbmUgaGVh ZGVyIHdpdGggdGhlIG1vc3Qgc2VjdXJlZCBhbGdvcml0aG0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+IDxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PGRpdj48ZGl2PjxkaXY+PHA+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gRGF2aWQgTWFjaWVqYWsgWzxhIGhyZWY9Im1haWx0bzpkbWFjaWVqYWtAZm9ydGluZXQuY29t Ij5tYWlsdG86ZG1hY2llamFrQGZvcnRpbmV0LmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gRnJp ZGF5LCBBdWd1c3QgMzEsIDIwMTIgMTA6MTcgQU08YnI+PGI+VG86PC9iPiBTaGVraC1ZdXNlZiwg UmlmYWF0IChSaWZhYXQpPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2h0dHAtYXV0aF0gSFRUUCBE aWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIEFsZ29yaXRobSBVcGRhdGU8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PHA+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48cD5PbiAw OC8zMS8yMDEyIDAzOjQ2IFBNLCBTaGVraC1ZdXNlZiwgUmlmYWF0IChSaWZhYXQpIHdyb3RlOjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPjxwPkhlbGxvLDxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPjxwPlRoZSBEaWdlc3QgbWVjaGFuaXNtLCB3aWRlbHkgdXNlZCBpbiBTSVAgbmV0 d29ya3MsIGlzIGJhc2VkIG9uIHRoZSBIVFRQIERpZ2VzdCBtZWNoYW5pc20gZGVmaW5lZCBpbiBS RkMgMjYxNy48bzpwPjwvbzpwPjwvcD48cD5UaGUgSFRUUCBEaWdlc3QgbWVjaGFuaXNtIHN0YXRl cyB0aGF0IE1ENSBpcyB0aGUgYWxnb3JpdGhtIHRvIGJlIHVzZWQsIGFuZCB3aGlsZSBpdCBhbGxv d3Mgb3RoZXIgYWxnb3JpdGhtcyB0byBiZSBhZGRlZCAocGVyIHRoZSAndG9rZW4nIGRlZmluZWQg aW4gU2VjdGlvbiAzLjIuMSwgYWxnb3JpdGhtID0gJnF1b3Q7YWxnb3JpdGhtJnF1b3Q7ICZxdW90 Oz0mcXVvdDsgKCAmcXVvdDtNRDUmcXVvdDsgfCAmcXVvdDtNRDUtc2VzcyZxdW90OyB8IHRva2Vu ICkpLCBubyBvdGhlciBhbGdvcml0aG0gaXMgc3BlY2lmaWVkLjxvOnA+PC9vOnA+PC9wPjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwPkluIDIwMDggdGhlIFVTLUNFUlQgaXNzdWVkIGEgbm90ZSB0 aGF0IE1ENSAmcXVvdDtzaG91bGQgYmUgY29uc2lkZXJlZCBjcnlwdG9ncmFwaGljYWxseSBicm9r ZW4gYW5kIHVuc3VpdGFibGUgZm9yIGZ1cnRoZXIgdXNlJnF1b3Q7LiBUaGUgZm9sbG93aW5nIGRy YWZ0IGlzIGFuIGF0dGVtcHQgdG8gc3BlY2lmeSBleHRlbnNpb25zIHRvIHRoZSBIVFRQIERpZ2Vz dCBBY2Nlc3MgQXV0aGVudGljYXRpb24gc2NoZW1lIGJ5IGFkZGluZyBzdXBwb3J0IGZvciB0aGUg U0hBMSBhbmQgU0hBMiBzdWl0ZSBvZiBoYXNoIGFsZ29yaXRobXMuPG86cD48L286cD48L3A+PHA+ Jm5ic3A7PG86cD48L286cD48L3A+PHA+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYWhyZW5zLWh0dHBiaXMtZGlnZXN0LWF1dGgtdXBkYXRlLz9pbmNsdWRl X3RleHQ9MSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWhyZW5zLWh0 dHBiaXMtZGlnZXN0LWF1dGgtdXBkYXRlLz9pbmNsdWRlX3RleHQ9MTwvYT48bzpwPjwvbzpwPjwv cD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD5PdXIg aW5pdGlhbCBnb2FsIHdhcyB0byBhZGRyZXNzIHRoZSBpc3N1ZSBmb3IgU0lQLCBidXQgd2hlbiB3 ZSBkaXNjdXNzZWQgdGhpcyB0b3BpYyBvZmZsaW5lIHdpdGggTWFyayBOb3R0aW5naGFtIChIVFRQ YmlzIGNoYWlyKSBhbmQgVG9iaWFzIEdvbmRyb20gKFdlYlNlYyBjby1jaGFpciksIHRoZXkgc3Vn Z2VzdGVkIHRvIHVzIHRvIHN1Ym1pdCBpdCBpbiB0aGUgY29udGV4dCBvZiBIVFRQYmlzIHRvIGFs bG93IHRoZSBncm91cCB0byBjb25zaWRlciBIVFRQIERpZ2VzdCBhcyBvbmUgb2YgdGhlIG1lY2hh bmlzbXMgZm9yIEhUVFAgMi4wLjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwPldlIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGl0IGlmIHBlb3BsZSBjYW4gcmV2aWV3IHRo ZSBkcmFmdCBhbmQgcHJvdmlkZSB1cyB3aXRoIHRoZWlyIGZlZWRiYWNrIG9uIHRoZSBmb2xsb3dp bmc6PG86cD48L286cD48L3A+PHA+MS4gVGhlIGJhc2ljIGlkZWEgb2YgZXh0ZW5kaW5nIFJGQzI2 MTcgdG8gc3VwcG9ydCBvdGhlciBhbGdvcml0aG1zLjxvOnA+PC9vOnA+PC9wPjxwPjIuIEluY2x1 ZGluZyB0aGUgZXh0ZW5kZWQgSFRUUCBEaWdlc3QgbWVjaGFuaXNtIGluIEhUVFAgMi4wLjxvOnA+ PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwPlJlZ2FyZHMsPG86cD48L286cD48 L3A+PHA+UmlmYWF0PG86cD48L286cD48L3A+PHA+Jm5ic3A7PG86cD48L286cD48L3A+PHAgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+aHR0cC1hdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+PHByZT48 YSBocmVmPSJtYWlsdG86aHR0cC1hdXRoQGlldGYub3JnIj5odHRwLWF1dGhAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3ByZT48cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaHR0cC1hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2h0dHAtYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPjwvYmxvY2txdW90ZT48cCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5IaSBSaWZhYXQsPGJyPjxicj55ZXMgaSBiZWxpZXZl IGl0J3MgYSBnb29kIGlkZWEgdG8gdXBkYXRlIHRoaXMgb2xkIHJmYyB3aXRoIHNvbWUgb3RoZXIg aGFzaCBhbGdvcy4gPGJyPk1vcmVvdmVyLCBvbiBwYWdlIDYtNyBpIGFtIG5vdCBzdXJlIGFib3V0 IHRoZSBleGFtcGxlIHlvdSBwdXQuPGJyPllvdSBtZWFuIDImbmJzcDsgV1dXLUF1dGhlbnRpY2F0 ZTogRGlnZXN0IGFyZSBzZW50IHRvIGxldCB0aGUgY2xpZW50IGNob29zZSB0aGUgYWxnbyA/PGJy Pjxicj50aGFua3MsPGJyPmRhdmlkPGJyPjxicj48YnI+PG86cD48L286cD48L3A+PGRpdj48cD4t LSA8bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5EYXZpZCBNYWNpZWphayA8 YnI+U3IuIFNlY3VyaXR5IFJlc2VhcmNoZXIgPGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5Gb3J0aW5ldCAtIFRoZSBOZXcgR2VuZXJhdGlv biBvZiBTZWN1cmUgR2F0ZXdheXM8L3NwYW4+PC9zdHJvbmc+PGJyPjEyMCBydWUgQWxiZXJ0IENh cXVvdCB8IDA2NTYwLCBTb3BoaWEgQW50aXBvbGlzIHwgRnJhbmNlIDxicj5QR1AgS2V5IElEOiBB MzBBNzdFRCA8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojOTk5OTk5Jz5UaGlz IG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbmFsIGFuZCBjb25maWRlbnRp YWwgdXNlIG9mIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIG1lc3NhZ2UgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRp b24gb3IgY29weWluZyBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC48L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PHA+PGI+Jm5ic3A7PC9iPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz4m bmJzcDs8bzpwPjwvbzpwPjwvcD48cD48Yj4qKiogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3By aWV0YXJ5IG1hdGVyaWFsIGFuZCBpbmZvcm1hdGlvbiBhbmQgYXJlIGludGVuZGVkIG9ubHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmV2 aWV3LCB1c2UsIGRpc2Nsb3N1cmUsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5 aW5nIG9mIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVzdHJveSB0aGlzIGUtbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFuZCBhbGwgY29waWVzLCB3aGV0aGVyIGVsZWN0cm9uaWMgb3IgcHJp bnRlZC4gUGxlYXNlIGFsc28gbm90ZSB0aGF0IGFueSB2aWV3cywgb3BpbmlvbnMsIGNvbmNsdXNp b25zIG9yIGNvbW1pdG1lbnRzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgdGhl IHZpZXdzIG9mIEZvcnRpbmV0LCBJbmMuLCBpdHMgYWZmaWxpYXRlcywgYW5kIGVtYWlscyBhcmUg bm90IGJpbmRpbmcgb24gRm9ydGluZXQgYW5kIG9ubHkgYSB3cml0aW5nIG1hbnVhbGx5IHNpZ25l ZCBieSBGb3J0aW5ldCdzIEdlbmVyYWwgQ291bnNlbCBjYW4gYmUgYSBiaW5kaW5nIGNvbW1pdG1l bnQgb2YgRm9ydGluZXQgdG8gRm9ydGluZXQncyBjdXN0b21lcnMgb3IgcGFydG5lcnMuIFRoYW5r IHlvdS4gKioqIDwvYj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2Vu dGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PHA+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48cD4tLSA8bzpwPjwvbzpwPjwvcD48cD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojNjY2NjY2Jz5EYXZpZCBNYWNpZWphayA8YnI+U3IuIFNlY3VyaXR5IFJlc2VhcmNo ZXIgPGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5Gb3J0aW5ldCAtIFRoZSBOZXcgR2VuZXJhdGlvbiBvZiBTZWN1cmUgR2F0ZXdheXM8L3Nw YW4+PC9zdHJvbmc+PGJyPjEyMCBydWUgQWxiZXJ0IENhcXVvdCB8IDA2NTYwLCBTb3BoaWEgQW50 aXBvbGlzIHwgRnJhbmNlIDxicj5QR1AgS2V5IElEOiBBMzBBNzdFRCA8L3NwYW4+PG86cD48L286 cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojOTk5OTk5Jz5UaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25s eSBmb3IgdGhlIHBlcnNvbmFsIGFuZCBjb25maWRlbnRpYWwgdXNlIG9mIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIG1lc3NhZ2UgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg cmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIG1l c3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PHA+PGI+Jm5ic3A7PC9iPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1j ZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD48 Yj4qKiogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IG1hdGVyaWFsIGFuZCBpbmZv cm1hdGlvbiBhbmQgYXJlIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGludGVuZGVk IHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUsIGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVzdHJveSB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhbGwg Y29waWVzLCB3aGV0aGVyIGVsZWN0cm9uaWMgb3IgcHJpbnRlZC4gUGxlYXNlIGFsc28gbm90ZSB0 aGF0IGFueSB2aWV3cywgb3BpbmlvbnMsIGNvbmNsdXNpb25zIG9yIGNvbW1pdG1lbnRzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBh bmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgdGhlIHZpZXdzIG9mIEZvcnRpbmV0LCBJbmMu LCBpdHMgYWZmaWxpYXRlcywgYW5kIGVtYWlscyBhcmUgbm90IGJpbmRpbmcgb24gRm9ydGluZXQg YW5kIG9ubHkgYSB3cml0aW5nIG1hbnVhbGx5IHNpZ25lZCBieSBGb3J0aW5ldCdzIEdlbmVyYWwg Q291bnNlbCBjYW4gYmUgYSBiaW5kaW5nIGNvbW1pdG1lbnQgb2YgRm9ydGluZXQgdG8gRm9ydGlu ZXQncyBjdXN0b21lcnMgb3IgcGFydG5lcnMuIFRoYW5rIHlvdS4gKioqIDwvYj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNl bnRlcic+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+PGRpdiBjbGFzcz1Nc29O b3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9z cGFuPjwvYj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4qKiogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IG1hdGVyaWFsIGFuZCBp bmZvcm1hdGlvbiBhbmQgYXJlIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUs IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVzdHJveSB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBh bGwgY29waWVzLCB3aGV0aGVyIGVsZWN0cm9uaWMgb3IgcHJpbnRlZC4gUGxlYXNlIGFsc28gbm90 ZSB0aGF0IGFueSB2aWV3cywgb3BpbmlvbnMsIGNvbmNsdXNpb25zIG9yIGNvbW1pdG1lbnRzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ciBhbmQgZG8gbm90IG5lY2Vzc2FyaWx5IHJlZmxlY3QgdGhlIHZpZXdzIG9mIEZvcnRpbmV0LCBJ bmMuLCBpdHMgYWZmaWxpYXRlcywgYW5kIGVtYWlscyBhcmUgbm90IGJpbmRpbmcgb24gRm9ydGlu ZXQgYW5kIG9ubHkgYSB3cml0aW5nIG1hbnVhbGx5IHNpZ25lZCBieSBGb3J0aW5ldCdzIEdlbmVy YWwgQ291bnNlbCBjYW4gYmUgYSBiaW5kaW5nIGNvbW1pdG1lbnQgb2YgRm9ydGluZXQgdG8gRm9y dGluZXQncyBjdXN0b21lcnMgb3IgcGFydG5lcnMuIFRoYW5rIHlvdS4gKioqIDxvOnA+PC9vOnA+ PC9zcGFuPjwvYj48L3A+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0 ZXh0LWFsaWduOmNlbnRlcic+PGI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0y IHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvYj48L2Rpdj48L2Rpdj48L2Rpdj48 L2JvZHk+PC9odG1sPg== --_000_6369CB70BFD88942B9705AC1E639A338232A2BB2EBDCUS1MBEX4glo_-- From turners@ieca.com Tue Sep 11 07:05:19 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 DE21121F87FE for ; Tue, 11 Sep 2012 07:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FxKqaWwP8EI for ; Tue, 11 Sep 2012 07:05:19 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.144.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8A21F87FF for ; Tue, 11 Sep 2012 07:05:19 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id EFE301CC4B659; Tue, 11 Sep 2012 09:05:18 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id E2D791CC4B638 for ; Tue, 11 Sep 2012 09:05:18 -0500 (CDT) Received: from [108.18.174.220] (port=59516 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TBR5a-0000Oi-O3 for http-auth@ietf.org; Tue, 11 Sep 2012 09:05:18 -0500 Message-ID: <504F451E.6070805@ieca.com> Date: Tue, 11 Sep 2012 10:05:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:59516 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [http-auth] http-auth BOF 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, 11 Sep 2012 14:05:20 -0000 As you're no doubt aware, http-bis chucked the http-auth mechanisms out in Vancouver. I'd like to have a forum to discuss http-auth options and ultimately publish them. One idea is to create a WG in the security area and publish the proposals on the experimental track. There's four that I've seen (in no particular order): - draft-oiwa-* - draft-farrell-httpbis-hoba - draft-melnikov-httpbis-scram-auth - draft-williams-httpbis-auth-classification Does this sounds like a plan? If it does, then let's chat about it here. spt PS - One of things I'd need to get a BOF going is for somebody [1] to ask for a BOF. I'd be best if more than one author set asked too. [1] In this instance Stephen F. doesn't count ;) From julian.reschke@gmx.de Tue Sep 11 07:10: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 3A61221F8803 for ; Tue, 11 Sep 2012 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hngc4AHX28Pq for ; Tue, 11 Sep 2012 07:10:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DAA0421F868A for ; Tue, 11 Sep 2012 07:10:54 -0700 (PDT) Received: (qmail invoked by alias); 11 Sep 2012 14:10:53 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 11 Sep 2012 16:10:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18B3k5o8P4Biqa09P8egQjzJk+pY6nTUPQDB6syC0 j4RHtTe28zPGUR Message-ID: <504F466A.3000203@gmx.de> Date: Tue, 11 Sep 2012 16:10:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sean Turner References: <504F451E.6070805@ieca.com> In-Reply-To: <504F451E.6070805@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] http-auth BOF 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, 11 Sep 2012 14:10:56 -0000 On 2012-09-11 16:05, Sean Turner wrote: > As you're no doubt aware, http-bis chucked the http-auth mechanisms out > in Vancouver. I'd like to have a forum to discuss http-auth options and > ultimately publish them. One idea is to create a WG in the security > area and publish the proposals on the experimental track. There's four > that I've seen (in no particular order): > > - draft-oiwa-* > - draft-farrell-httpbis-hoba > - draft-melnikov-httpbis-scram-auth > - draft-williams-httpbis-auth-classification > > Does this sounds like a plan? If it does, then let's chat about it here. > > spt > > PS - One of things I'd need to get a BOF going is for somebody [1] to > ask for a BOF. I'd be best if more than one author set asked too. +1 in general. But let's fix I18N in Basic auth: http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html But let's browsers to provide logout() functionality via Javascript Best regards, Julian From turners@ieca.com Tue Sep 11 07:37:27 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 DB22421F847D for ; Tue, 11 Sep 2012 07:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxoQ1g48XIKe for ; Tue, 11 Sep 2012 07:37:27 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.142.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44521F8475 for ; Tue, 11 Sep 2012 07:37:27 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 8ED5712B53AD1; Tue, 11 Sep 2012 09:37:27 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 831E912B53AA4 for ; Tue, 11 Sep 2012 09:37:27 -0500 (CDT) Received: from [108.18.174.220] (port=59697 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TBRag-0002cd-GR for http-auth@ietf.org; Tue, 11 Sep 2012 09:37:26 -0500 Message-ID: <504F4CA5.8060009@ieca.com> Date: Tue, 11 Sep 2012 10:37:25 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <504F451E.6070805@ieca.com> In-Reply-To: <504F451E.6070805@ieca.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) [108.18.174.220]:59697 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [http-auth] http-auth BOF 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, 11 Sep 2012 14:37:28 -0000 I knew I'd leave at least one off. We should add the following to the list: - draft-ahrens-httpbis-digest-auth-update spt On 9/11/12 10:05 AM, Sean Turner wrote: > As you're no doubt aware, http-bis chucked the http-auth mechanisms out > in Vancouver. I'd like to have a forum to discuss http-auth options and > ultimately publish them. One idea is to create a WG in the security > area and publish the proposals on the experimental track. There's four > that I've seen (in no particular order): > > - draft-oiwa-* > - draft-farrell-httpbis-hoba > - draft-melnikov-httpbis-scram-auth > - draft-williams-httpbis-auth-classification > > Does this sounds like a plan? If it does, then let's chat about it here. > > spt > > PS - One of things I'd need to get a BOF going is for somebody [1] to > ask for a BOF. I'd be best if more than one author set asked too. > > [1] In this instance Stephen F. doesn't count ;) > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From ynir@checkpoint.com Tue Sep 11 14:02:21 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 574B921F866A for ; Tue, 11 Sep 2012 14:02:21 -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 45tkgBWNFp-X for ; Tue, 11 Sep 2012 14:02:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3521F8669 for ; Tue, 11 Sep 2012 14:02:19 -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 q8BL2BFL008697; Wed, 12 Sep 2012 00:02:13 +0300 X-CheckPoint: {504FA6A8-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; Wed, 12 Sep 2012 00:02:10 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 12 Sep 2012 00:02:10 +0300 From: Yoav Nir To: Julian Reschke Date: Wed, 12 Sep 2012 00:02:09 +0300 Thread-Topic: [http-auth] http-auth BOF Thread-Index: Ac2QYLUbEDs5zdVYRyiN5hhQJuTq4w== Message-ID: <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> In-Reply-To: <504F466A.3000203@gmx.de> 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 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 11 Sep 2012 21:02:21 -0000 On Sep 11, 2012, at 5:10 PM, Julian Reschke wrote: > On 2012-09-11 16:05, Sean Turner wrote: >> As you're no doubt aware, http-bis chucked the http-auth mechanisms out >> in Vancouver. I'd like to have a forum to discuss http-auth options and >> ultimately publish them. One idea is to create a WG in the security >> area and publish the proposals on the experimental track. There's four >> that I've seen (in no particular order): >>=20 >> - draft-oiwa-* >> - draft-farrell-httpbis-hoba >> - draft-melnikov-httpbis-scram-auth >> - draft-williams-httpbis-auth-classification >>=20 >> Does this sounds like a plan? If it does, then let's chat about it here= . >>=20 >> spt >>=20 >> PS - One of things I'd need to get a BOF going is for somebody [1] to >> ask for a BOF. I'd be best if more than one author set asked too. >=20 > +1 in general. +1 as well. > > But let's fix I18N in Basic auth:=20 > http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html > Why do we need to fix sending your password in the clear? > > But let's browsers to provide logout() functionality via Javascript > Logout is terminating a session. Do we have a definition of "session" that'= s different from "the lifespan of a session cookie"? What would you want th= e javascript to do, and how can you tell that it's doing it? Yoav= From tim-research@sentinelchicken.org Tue Sep 11 15:29: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 B3ED521F8672 for ; Tue, 11 Sep 2012 15:29:59 -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 tjiLjmL9TiSb for ; Tue, 11 Sep 2012 15:29:59 -0700 (PDT) Received: from sentinelchicken.org (laim.sentinelchicken.org [96.126.98.9]) by ietfa.amsl.com (Postfix) with SMTP id 4F8FB21F8555 for ; Tue, 11 Sep 2012 15:29:58 -0700 (PDT) Received: (qmail 13988 invoked from network); 11 Sep 2012 22:29:58 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by lelantos.sentinelchicken.org with SMTP; 11 Sep 2012 22:29:58 -0000 Received: (qmail 31513 invoked from network); 11 Sep 2012 22:40:49 -0000 Received: from unknown (HELO shannon.sentinelchicken.org) (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 11 Sep 2012 22:40:49 -0000 Received: (nullmailer pid 8266 invoked by uid 1000); Tue, 11 Sep 2012 22:29:50 -0000 Date: Tue, 11 Sep 2012 15:29:50 -0700 From: Tim To: Yoav Nir Message-ID: <20120911222950.GH2295@sentinelchicken.org> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 11 Sep 2012 22:29:59 -0000 > > > > But let's browsers to provide logout() functionality via Javascript > > > > Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that it's doing it? Yeah, I kinda thought we had settled on making this part of HTTP, either through new auth protocols more more generally. This doesn't preclude doing it in JavaScript as well (as nonstandard extensions/apis already allow), but doing it at a lower level will allow logouts to work for non-JavaScript aware clients. tim From nico@cryptonector.com Tue Sep 11 15:41: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 611E521E804A for ; Tue, 11 Sep 2012 15:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOIoCRP5zeuX for ; Tue, 11 Sep 2012 15:41:28 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 94E6721E8049 for ; Tue, 11 Sep 2012 15:41:28 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 0F247768064 for ; Tue, 11 Sep 2012 15:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=P58k8I7kNF7DEeqUi7UL qSaxl6Q=; b=Rayr2Zd8s851bDwK0U2syGiANOg0AOoRugYD1cgydDLfs587VBZ5 FTrKSxZPWtrJD4zShbsCa03uoe43R1+JirPaZ9IaQT3NJSKIelEEN/QFqeVWaS03 LbLblKYl8eGYT7jyaX6JrQdHiw5t9qEvbZpCnYwI48m8UH02XZNZ/jY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id EA140768059 for ; Tue, 11 Sep 2012 15:41:27 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1438570pbb.31 for ; Tue, 11 Sep 2012 15:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.228.234 with SMTP id sl10mr13370805pbc.25.1347403287653; Tue, 11 Sep 2012 15:41:27 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Tue, 11 Sep 2012 15:41:27 -0700 (PDT) In-Reply-To: <504F451E.6070805@ieca.com> References: <504F451E.6070805@ieca.com> Date: Tue, 11 Sep 2012 17:41:27 -0500 Message-ID: From: Nico Williams To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] http-auth BOF 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, 11 Sep 2012 22:41:29 -0000 On Tue, Sep 11, 2012 at 9:05 AM, Sean Turner wrote: > As you're no doubt aware, http-bis chucked the http-auth mechanisms out in > Vancouver. I'd like to have a forum to discuss http-auth options and > ultimately publish them. One idea is to create a WG in the security area > and publish the proposals on the experimental track. There's four that I've > seen (in no particular order): > > - draft-oiwa-* > - draft-farrell-httpbis-hoba > - draft-melnikov-httpbis-scram-auth > - draft-williams-httpbis-auth-classification > > Does this sounds like a plan? If it does, then let's chat about it here. Actually, please include draft-williams-http-rest-auth (RESTauth, successor to REST-GSS) and remove draft-williams-httpbis-auth-classification. (No one seems interested in draft-williams-httpbis-auth-classification. Whereas there is some interest in RESTauth (some in the IETF and at least one party outside interested in deploying it in the enterprise.) Nico -- From y.oiwa@aist.go.jp Tue Sep 11 19:01:04 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 DE7EB21F8550 for ; Tue, 11 Sep 2012 19:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyvbDf4AURHQ for ; Tue, 11 Sep 2012 19:01:04 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2408C21F854F for ; Tue, 11 Sep 2012 19:01:04 -0700 (PDT) Received: from mail-ie0-f198.google.com ([209.85.223.198]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUE/s37ZhwwrEsPHowPM4vVSZ9A/wSoIQ@postini.com; Tue, 11 Sep 2012 19:01:04 PDT Received: by iebc10 with SMTP id c10so3759817ieb.1 for ; Tue, 11 Sep 2012 19:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/l0WduVEcnDZWSUn6GOzIrUdE6TXoMddO+KmwSlO2m4=; b=jKYfd8bnD5YecQQAhrUG3wtw1M0r8rCUexeBOT01sfGTDJ9fJfdFBTU1IInoOwnNJ5 Y6lnXvAIGAqxPvak1gH7mejncdxaXmvAtXdPzNCZoM1HEgqoL4YXF2h0IhWye3qAEHAt SvV2UxJKXYtcaKPeKrfnc8zX/AMqYyA4DzhNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/l0WduVEcnDZWSUn6GOzIrUdE6TXoMddO+KmwSlO2m4=; b=n1L5eGJqDCJRoCvOgVvrb2xT7gFm1l5muusp79R6BhH4PEs3UuAIAz0JmSuOFMN9Sb oxVprHFoKDonwEMFli47WqX1vb9XDZzUcrW89E2ntcPxqTrf4+jzWIEBgP6jEoHYjY9v fU6yufbaQ2Aul0vNMJzfSpWT3vp/wdcgidbStO+BTfiRYxD9sXiNMN9eUNpEAVILBVPr +WsvHHIBKDtVgjTUesuRnEion1UHxohATzAoI5nobxvZlSaa0WU5AR5bYM2mJiUKY8wI hzvdf6Ah+yYWjC0TRBpOR8+I+Bt+K7MIdpyzQZzS5nY/ooVyw8998/0BE1vmF1abR21v 953Q== Received: by 10.50.180.227 with SMTP id dr3mr3298594igc.1.1347415263492; Tue, 11 Sep 2012 19:01:03 -0700 (PDT) Received: by 10.50.180.227 with SMTP id dr3mr3298587igc.1.1347415263370; Tue, 11 Sep 2012 19:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.90.103 with HTTP; Tue, 11 Sep 2012 19:00:43 -0700 (PDT) In-Reply-To: <504F451E.6070805@ieca.com> References: <504F451E.6070805@ieca.com> From: Yutaka OIWA Date: Wed, 12 Sep 2012 11:00:43 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnoQSxPCfpNXN99Ro8HOgJCLWi1Pq5kWcsi7uG4VgBREu89oGxlhmoyIGM3CdnrMatN4T+ka5KaCrxtB/zgza6dWOdCPBUSWKYTfHceY61gszYZ/CX3Wp9KDgvX97Ha8035h8cQucpdq+aaLT5RfJSmXJoGtw== Cc: http-auth@ietf.org Subject: Re: [http-auth] http-auth BOF 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: Wed, 12 Sep 2012 02:01:05 -0000 Dear all, 2012/9/11 Sean Turner : > Does this sounds like a plan? If it does, then let's chat about it here. +1. Really good points to start. > PS - One of things I'd need to get a BOF going is for somebody [1] to ask > for a BOF. I'd be best if more than one author set asked too. Is it meaning I should raise the hand explicitly? (^_^)/ -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From julian.reschke@gmx.de Wed Sep 12 00:02: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 0E23821E803D for ; Wed, 12 Sep 2012 00:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 jVoF6V1x6zh8 for ; Wed, 12 Sep 2012 00:02:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8AD4121E8041 for ; Wed, 12 Sep 2012 00:02:13 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2012 07:02:11 -0000 Received: from p5DD96328.dip.t-dialin.net (EHLO [192.168.2.117]) [93.217.99.40] by mail.gmx.net (mp036) with SMTP; 12 Sep 2012 09:02:11 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+n6FF8Lvyn9B1VIKuP6xVMsKXLjNr8qVDxeRBMGg G96N3PO4wSZhVj Message-ID: <50503370.30109@gmx.de> Date: Wed, 12 Sep 2012 09:02:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yoav Nir References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> In-Reply-To: <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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: Wed, 12 Sep 2012 07:02:15 -0000 On 2012-09-11 23:02, Yoav Nir wrote: > > On Sep 11, 2012, at 5:10 PM, Julian Reschke wrote: > >> On 2012-09-11 16:05, Sean Turner wrote: >>> As you're no doubt aware, http-bis chucked the http-auth mechanisms out >>> in Vancouver. I'd like to have a forum to discuss http-auth options and >>> ultimately publish them. One idea is to create a WG in the security >>> area and publish the proposals on the experimental track. There's four >>> that I've seen (in no particular order): >>> >>> - draft-oiwa-* >>> - draft-farrell-httpbis-hoba >>> - draft-melnikov-httpbis-scram-auth >>> - draft-williams-httpbis-auth-classification >>> >>> Does this sounds like a plan? If it does, then let's chat about it here. >>> >>> spt >>> >>> PS - One of things I'd need to get a BOF going is for somebody [1] to >>> ask for a BOF. I'd be best if more than one author set asked too. >> >> +1 in general. > > +1 as well. > >> >> But let's fix I18N in Basic auth: >> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >> > > Why do we need to fix sending your password in the clear? Because it's widely used with TLS and causes real-world interop problems. >> >> But let's browsers to provide logout() functionality via Javascript >> > > Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that it's doing it? What do cookies have to do with this? The problem with HTTP authentication as of today is that there's no well-defined, interoperable way to stop the browser sending the credentials you entered. Again, this is a real-world problem that stops people from using HTTP auth in the first place. Best regards, Julian From ynir@checkpoint.com Wed Sep 12 14:47:54 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 2107421F85B4 for ; Wed, 12 Sep 2012 14:47:54 -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 L+7E4Hy0bE7y for ; Wed, 12 Sep 2012 14:47:53 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CACDA21F8503 for ; Wed, 12 Sep 2012 14:47:52 -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 q8CLliDA023942; Thu, 13 Sep 2012 00:47:44 +0300 X-CheckPoint: {505102C9-8-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, 13 Sep 2012 00:47:36 +0300 From: Yoav Nir To: Julian Reschke Date: Thu, 13 Sep 2012 00:46:03 +0300 Thread-Topic: [http-auth] http-auth BOF Thread-Index: Ac2RMAHqunt9A3yeTqWS/Pk5WaGm4w== Message-ID: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> In-Reply-To: <50503370.30109@gmx.de> 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 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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: Wed, 12 Sep 2012 21:47:54 -0000 On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>> >>> But let's fix I18N in Basic auth: >>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.htm= l >>> >>=20 >> Why do we need to fix sending your password in the clear? >=20 > Because it's widely used with TLS and causes real-world interop problems. Strange. I never see them. In GMail, Facebook, CNN and bank websites you on= ly see form-based authentication. And those forms work well with internatio= nalization. >>> >>> But let's browsers to provide logout() functionality via Javascript >>> >>=20 >> Logout is terminating a session. Do we have a definition of "session" th= at's different from "the lifespan of a session cookie"? What would you want= the javascript to do, and how can you tell that it's doing it? >=20 > What do cookies have to do with this? You don't see a lot of websites that ask for the credentials with every req= uest. They ask for them once (usually via a form), and plant a session cook= ie to remember you by. Do this on a public computer, and the next person co= mes in and is still logged on as you. > The problem with HTTP authentication as of today is that there's no=20 > well-defined, interoperable way to stop the browser sending the=20 > credentials you entered. Again, this is a real-world problem that stops=20 > people from using HTTP auth in the first place. I see. Good point. But adding this to Javascript does not show the user that it's happened. Ho= w do I know that the function has been run? Seems to me that the "session", whether it's tied to a cookie, to cached cr= edentials, or to a new field in http/2.0 should be indicated in the browser= , and that log out should be time-based, explicit, or based on browsing els= ewhere. Yoav From julian.reschke@gmx.de Wed Sep 12 15:00:27 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 A3F3121F8652 for ; Wed, 12 Sep 2012 15:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 zWnSK+9Tz-Wd for ; Wed, 12 Sep 2012 15:00:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7BFE321F8618 for ; Wed, 12 Sep 2012 15:00:26 -0700 (PDT) Received: (qmail invoked by alias); 12 Sep 2012 22:00:25 -0000 Received: from p5DD97E38.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.126.56] by mail.gmx.net (mp034) with SMTP; 13 Sep 2012 00:00:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19FB3Ee7DxFW5BK60e9nCuhz75qmlawWJm9DeLWc9 1DcglxEBd9xv/E Message-ID: <505105F5.9060500@gmx.de> Date: Thu, 13 Sep 2012 00:00:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yoav Nir References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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: Wed, 12 Sep 2012 22:00:27 -0000 On 2012-09-12 23:46, Yoav Nir wrote: > > On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>>> >>>> But let's fix I18N in Basic auth: >>>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >>>> >>> >>> Why do we need to fix sending your password in the clear? >> >> Because it's widely used with TLS and causes real-world interop problems. > > Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization. Form based auth doesn't work with programmatic clients. If you're happy with form-based auth, why are you even interested in HTTP authentication? >>>> >>>> But let's browsers to provide logout() functionality via Javascript >>>> >>> >>> Logout is terminating a session. Do we have a definition of "session" that's different from "the lifespan of a session cookie"? What would you want the javascript to do, and how can you tell that it's doing it? >> >> What do cookies have to do with this? > > You don't see a lot of websites that ask for the credentials with every request. They ask for them once (usually via a form), and plant a session cookie to remember you by. Do this on a public computer, and the next person comes in and is still logged on as you. That's cookie-based authentication, not HTTP authentication. I thought we're discussing the latter. >> The problem with HTTP authentication as of today is that there's no >> well-defined, interoperable way to stop the browser sending the >> credentials you entered. Again, this is a real-world problem that stops >> people from using HTTP auth in the first place. > > I see. Good point. > > But adding this to Javascript does not show the user that it's happened. How do I know that the function has been run? > > Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explicit, or based on browsing elsewhere. Maybe. We need to come up with a list of things that need to happen to make HTTP auth usable in practice. I'm aware of the UI issue (skinning the login), and the logout problem. What else is needed? From y.oiwa@aist.go.jp Wed Sep 12 18:20: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 794FA21E803F for ; Wed, 12 Sep 2012 18:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu709kgM57i0 for ; Wed, 12 Sep 2012 18:20:25 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id AE94121E803A for ; Wed, 12 Sep 2012 18:20:24 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUFE02I9m727Q8l+5FiBVKXpuzQSoGHhz@postini.com; Wed, 12 Sep 2012 18:20:24 PDT Received: by ieak13 with SMTP id k13so4422171iea.31 for ; Wed, 12 Sep 2012 18:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oxDi0N0SAy6smAR0bbcf3IiRP6ZspfUyaDf5N56SBtA=; b=PoHArqpqYix6ODbUwjupGtZRdLAVT2yES+UxMrEDCLV6YQlmxzLBqMl/LsQMiPTBL1 CgfEWH2VwEXuZm4M1RHr/7AB48R4ztaQ/PUGre5Edas4FMO3fJ3NsYGkV0GE0V1nrlYZ oLmA5aqp/W+HBrSqJBmkgCT782PoXjTz8zB4g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=oxDi0N0SAy6smAR0bbcf3IiRP6ZspfUyaDf5N56SBtA=; b=DKr+634i+Qqle43ZiFk3xYpiXm+eyfvQY/vXChMCWFLYZv0GUbr0zceERmaZ8iaCeP q8+EhCoHb6DBR00DU5Ct293S6mVriGAILJxTCchDBySoIDG+8VAxx7wh32Rz09nPl49B 3KoLMXdoyDwRuJduOr/Ii11QPpK3/rNPRjawr9+qTqyoJPqSEE3QiDZQfbW04M6JLRpy UDBRpO/6y8gCsHA4DlRzlPVNm8D8tV4ym0DK/beeZCR5G/30r0JNj91Qgl5/FjrwKFdU 13Hqtrw92f+XtcqWbQcDqlDNgmCFv/Br1mW0A2FXdhxFd8plLrWaGQxwuGzPr6gRq0x1 uvcg== Received: by 10.50.47.167 with SMTP id e7mr383691ign.1.1347499223877; Wed, 12 Sep 2012 18:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.90.103 with HTTP; Wed, 12 Sep 2012 18:20:03 -0700 (PDT) In-Reply-To: <505105F5.9060500@gmx.de> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <505105F5.9060500@gmx.de> From: Yutaka OIWA Date: Thu, 13 Sep 2012 10:20:03 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmN9mo4v4Fkt+9E403x/XmcAvzRLc0pfoalGrhXrm7H+GHQBOFiZ49PgChZkCmmNialqX3w Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 01:20:26 -0000 Hi Julian, 2012/9/13 Julian Reschke : > Maybe. We need to come up with a list of things that need to happen to make > HTTP auth usable in practice. I'm aware of the UI issue (skinning the > login), and the logout problem. What else is needed? I had some strawman analysis (maybe not complete yet...) and summarized (as a protocol) in https://datatracker.ietf.org/doc/draft-oiwa-http-auth-extension/ . Maybe for this thread, it worth reading just a TOC of this draft. I put my goal on enabling current Form-and-cookie based Websites to use HTTP-based authentication. My current requirement list entries are: * Optional authentication (concurrent support for guest / authenticated users) * Redirection on unauthenticated cases only * Redirection hook on log-out * Timer-based expiration of authentication session (including 0-second "immediate" logout) First two things may be replaced by use of WWW-Authenticate headers with several non-401 statuses, but we will need more compatibility analysis of existing clients. In any way, we need "standardization" here. -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From ynir@checkpoint.com Thu Sep 13 03:04: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 91E1C21F8557 for ; Thu, 13 Sep 2012 03:04:43 -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 70KSKP7-3R8b for ; Thu, 13 Sep 2012 03:04:43 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9466821F8559 for ; Thu, 13 Sep 2012 03:04:42 -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 q8DA4AHv013129; Thu, 13 Sep 2012 13:04:14 +0300 X-CheckPoint: {5051AF5E-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 13 Sep 2012 13:04:10 +0300 From: Yoav Nir To: Julian Reschke Date: Thu, 13 Sep 2012 13:04:09 +0300 Thread-Topic: [http-auth] http-auth BOF Thread-Index: Ac2Rlx5muY7mWWHgRpaY7u4U87ORIg== Message-ID: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <505105F5.9060500@gmx.de> In-Reply-To: <505105F5.9060500@gmx.de> 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 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 10:04:43 -0000 On Sep 13, 2012, at 1:00 AM, Julian Reschke wrote: >>>>> >>>>> But let's browsers to provide logout() functionality via Javascript >>>>> >>>>=20 >>>> Logout is terminating a session. Do we have a definition of "session" = that's different from "the lifespan of a session cookie"? What would you wa= nt the javascript to do, and how can you tell that it's doing it? >>>=20 >>> What do cookies have to do with this? >>=20 >> You don't see a lot of websites that ask for the credentials with every = request. They ask for them once (usually via a form), and plant a session c= ookie to remember you by. Do this on a public computer, and the next person= comes in and is still logged on as you. >=20 > That's cookie-based authentication, not HTTP authentication. I thought=20 > we're discussing the latter. They're not mutually exclusive. You can authenticate every single request, = or you can authenticate once, and then the server can associate the session= cookie with you identity, and use the cookie to authenticate subsequent re= quests. It makes no difference if the single authentication was part of TLS= , part of HTTP, or form-based. If we adopt some kind of ZKPP where you need= to perform public key operations for each authentication, extending the au= thentication to subsequent requests may be very attractive. I don't know if= cookies as they are defined today are the appropriate way, but then logout= becomes as simple as deleting the cookie. >>> The problem with HTTP authentication as of today is that there's no >>> well-defined, interoperable way to stop the browser sending the >>> credentials you entered. Again, this is a real-world problem that stops >>> people from using HTTP auth in the first place. >>=20 >> I see. Good point. >>=20 >> But adding this to Javascript does not show the user that it's happened.= How do I know that the function has been run? >>=20 >> Seems to me that the "session", whether it's tied to a cookie, to cached= credentials, or to a new field in http/2.0 should be indicated in the brow= ser, and that log out should be time-based, explicit, or based on browsing = elsewhere. >=20 > Maybe. We need to come up with a list of things that need to happen to=20 > make HTTP auth usable in practice. I'm aware of the UI issue (skinning=20 > the login), and the logout problem. What else is needed? I think the big security issue is how I can tell the Facebook login page (w= here I'm supposed to enter my credentials) to the phisher's website that lo= oks exactly the same, where I'm not supposed to. ZKPP in Javascript doesn't= help, because the phisher can create a page that looks exactly the same an= d has plain text fields. Yoav From leifj@mnt.se Thu Sep 13 03:49:27 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 AD6FE21F8564 for ; Thu, 13 Sep 2012 03:49:27 -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 7Erzh81hXWHs for ; Thu, 13 Sep 2012 03:49:26 -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 8B4A421F8557 for ; Thu, 13 Sep 2012 03:49:26 -0700 (PDT) Received: from [192.36.125.227] (dhcp.pilsnet.sunet.se [192.36.125.227]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q8DAnLwi010545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2012 12:49:24 +0200 (CEST) Message-ID: <5051BA30.4020504@mnt.se> Date: Thu, 13 Sep 2012 12:49:20 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <504F451E.6070805@ieca.com> In-Reply-To: <504F451E.6070805@ieca.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 10:49:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/11/2012 04:05 PM, Sean Turner wrote: > As you're no doubt aware, http-bis chucked the http-auth mechanisms > out in Vancouver. I'd like to have a forum to discuss http-auth > options and ultimately publish them. One idea is to create a WG in > the security area and publish the proposals on the experimental > track. There's four that I've seen (in no particular order): > > - draft-oiwa-* - draft-farrell-httpbis-hoba - > draft-melnikov-httpbis-scram-auth - > draft-williams-httpbis-auth-classification > > Does this sounds like a plan? If it does, then let's chat about it > here. 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... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBRui8ACgkQ8Jx8FtbMZnfxsQCeNOkk/5jv1Uwmy4arR4eZJGmo BcUAoJ2tYA+lu2rXbBgjbot6dLd8KmJu =5REN -----END PGP SIGNATURE----- From nico@cryptonector.com Thu Sep 13 09:27:19 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 B350721F85ED for ; Thu, 13 Sep 2012 09:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-VhBkAwKQ-R for ; Thu, 13 Sep 2012 09:27:18 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 04F8521F85AE for ; Thu, 13 Sep 2012 09:27:11 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id EBBF921DE65 for ; Thu, 13 Sep 2012 09:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EOwXyeO5zL5WV46ux06N KwV4byo=; b=PU7OP4WAOa/1jrjTwLcxvl/nhbJOsXMZst60H5dlzBPWo6jjPbWZ rKC/FKC9E3WBkCMxFzK4CIUNkFJQCEo2CSNThwXZ9npVSMaGgj+0bVViaW5HmS6W h7kfxtNHSMix69AZDNjaikNr2mvaS0WXmvNDuHSqsdHzkvNjcibUSCQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id D57F821DE59 for ; Thu, 13 Sep 2012 09:27:10 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4202603pbb.31 for ; Thu, 13 Sep 2012 09:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.73 with SMTP id nu9mr298056pbb.59.1347553166528; Thu, 13 Sep 2012 09:19:26 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 13 Sep 2012 09:19:26 -0700 (PDT) In-Reply-To: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> Date: Thu, 13 Sep 2012 11:19:26 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 16:27:19 -0000 On Wed, Sep 12, 2012 at 4:46 PM, Yoav Nir wrote: > On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>>> >>>> But let's fix I18N in Basic auth: >>>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >>>> >>> >>> Why do we need to fix sending your password in the clear? >> >> Because it's widely used with TLS and causes real-world interop problems. > > Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization. Agreed. The problems with passwords over forms are not interop ones, they are security ones: - servers store hashes that are relatively easy to steal and then brute-force with offline dictionary attacks; - this method (passwords in forms POSTed over HTTPS) is 100% dependent on a very fallible TLS server PKI; - all too often the form is sent over HTTP, not HTTPS, so all too often there's no real security in the first place. >> The problem with HTTP authentication as of today is that there's no >> well-defined, interoperable way to stop the browser sending the >> credentials you entered. Again, this is a real-world problem that stops >> people from using HTTP auth in the first place. Any solution that's not entirely in the hands of the server (and therefore entirely dependent on the TLS server PKI) will require *proper* integration into the browser, *including* proper logout support, and UI indications of whether the user is logged in, and with what identity. If this is not possible then we must give up on HTTP authentication (for the browser anyways). > But adding this to Javascript does not show the user that it's happened. How do I know that the function has been run? In my conception there are native JavaScript interfaces to SASL or whatever, and when authentication succeeds the browser will indicate this to the user via some UI element (kinda like the old lock icon). I understand that browser folks have all but given up on such UI elements, and that there's full screen apps to worry about, and so on, but I don't think these are issues that cannot be overcome. > Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explicit, or based on browsing elsewhere. Indeed! Nico -- From hhalpin@w3.org Thu Sep 13 09:53:05 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6760121F84F2 for ; Thu, 13 Sep 2012 09:53:05 -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 xVcpiLubNxNC for ; Thu, 13 Sep 2012 09:53:04 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 68B2521F84F1 for ; Thu, 13 Sep 2012 09:53:04 -0700 (PDT) Received: from lputeaux-156-14-30-207.w82-127.abo.wanadoo.fr ([82.127.13.207] helo=[192.168.1.28]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TCCf1-0005li-5x for http-auth@ietf.org; Thu, 13 Sep 2012 12:53:03 -0400 Message-ID: <50520F65.6020604@w3.org> Date: Thu, 13 Sep 2012 18:52:53 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 16:53:05 -0000 On 09/13/2012 06:19 PM, Nico Williams wrote: > On Wed, Sep 12, 2012 at 4:46 PM, Yoav Nir wrote: >> On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>>>> >>>>> But let's fix I18N in Basic auth: >>>>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >>>>> >>>> Why do we need to fix sending your password in the clear? >>> Because it's widely used with TLS and causes real-world interop problems. >> Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization. > Agreed. > > The problems with passwords over forms are not interop ones, they are > security ones: > > - servers store hashes that are relatively easy to steal and then > brute-force with offline dictionary attacks; > > - this method (passwords in forms POSTed over HTTPS) is 100% > dependent on a very fallible TLS server PKI; > > - all too often the form is sent over HTTP, not HTTPS, so all too > often there's no real security in the first place. > >>> The problem with HTTP authentication as of today is that there's no >>> well-defined, interoperable way to stop the browser sending the >>> credentials you entered. Again, this is a real-world problem that stops >>> people from using HTTP auth in the first place. > Any solution that's not entirely in the hands of the server (and > therefore entirely dependent on the TLS server PKI) will require > *proper* integration into the browser, *including* proper logout > support, and UI indications of whether the user is logged in, and with > what identity. If this is not possible then we must give up on HTTP > authentication (for the browser anyways). Before we give up depression over this, I will add the W3C would like to help the IETF in this effort. The main issue holding us back is that there is no draft scheme that the major browser vendors support right now. However, we will try to have this discussion at W3C TPAC on Oct 31st (and thus shortly before Atlanta IETF BoF) to see if we can invoke interest in this topic again. In essence, I think most of us agree there just has to be some way for the browser to create in sort of "chrome pop up" so that whatever happens in that "chrome pop up for login" gets encrypted and shipped out to the JS, with the plaintext never seen by the JS, and of course better than HTTP Digest/Basic. Also, ideally this login can happen outside the browser (say at OS login) and then be shared with the browser. However, we are unlikely to get UI co-ordination in the chrome across browser vendors. Yet, we can specify that *something* needs to happen in the chrome that requires *user interaction* and then make sure every browser supports that *something* in test-cases. So I agree none of these problems are insurmountable. Also, I would add that this is larger problem than just rewriting HTTP Auth, as what is really needed is a superior identity/session manager (although how to do that while avoiding user confusion is tricky) so that a user can keep track of where they are logged in, and one would want to provide some kind of identity management API that could then be used by WebApps that need to figure out a user's identity. Furthermore, this session information should be portable across browsers. However, given that this already happens in Android, that session management APIs already exist in Mozilla, and that similar work can happen with WebIntents, and that its a clear and pressing need, I think we should move on the issue. I'd like to see one solution that's actually mature and implemented across browsers, and again, if there's a clear proposal, we will be more than happy to help on the API/browser front. I'm not sure if there's any possible relationship to the WebCrypto API, but that work is going nicely and FPWD should be published later today [1]. cheers, harry [1] http://www.w3.org/2012/webcrypto/WebCryptoAPI/ > > >> But adding this to Javascript does not show the user that it's happened. How do I know that the function has been run? > In my conception there are native JavaScript interfaces to SASL or > whatever, and when authentication succeeds the browser will indicate > this to the user via some UI element (kinda like the old lock icon). > I understand that browser folks have all but given up on such UI > elements, and that there's full screen apps to worry about, and so on, > but I don't think these are issues that cannot be overcome. > >> Seems to me that the "session", whether it's tied to a cookie, to cached credentials, or to a new field in http/2.0 should be indicated in the browser, and that log out should be time-based, explicit, or based on browsing elsewhere. > Indeed! > > Nico > -- > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nico@cryptonector.com Thu Sep 13 10:16:23 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 DA17C21F8575 for ; Thu, 13 Sep 2012 10:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL-r70rvAit0 for ; Thu, 13 Sep 2012 10:16:23 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1021F8564 for ; Thu, 13 Sep 2012 10:16:23 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id D252321DE7E for ; Thu, 13 Sep 2012 10:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zoOPSg/0nscecXhycW6f hpKRifw=; b=sFtve33CJ5PWV5YB5iqWfnFcd7X3cr9ew2aV2aYtR4UGxTqfDfiF ToCzp19gIOoAJq7QitOwCzt7fZDNT/xF97L+4U8vHC9QhcE3KorpzzWoi8EA1+3B ioQlLj/W+jxSziW1H9ujY+fTyLNNixbOUKnZ1pd6XzBGXVxBzshWmLs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9E3AE21DE6A for ; Thu, 13 Sep 2012 10:16:22 -0700 (PDT) Received: by dadf8 with SMTP id f8so1851843dad.31 for ; Thu, 13 Sep 2012 10:16:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.166 with SMTP id r6mr4254312pay.25.1347556582312; Thu, 13 Sep 2012 10:16:22 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 13 Sep 2012 10:16:22 -0700 (PDT) In-Reply-To: <50520F65.6020604@w3.org> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50520F65.6020604@w3.org> Date: Thu, 13 Sep 2012 12:16:22 -0500 Message-ID: From: Nico Williams To: Harry Halpin Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 17:16:24 -0000 On Thu, Sep 13, 2012 at 11:52 AM, Harry Halpin wrote: > On 09/13/2012 06:19 PM, Nico Williams wrote: >> Any solution that's not entirely in the hands of the server (and >> therefore entirely dependent on the TLS server PKI) will require >> *proper* integration into the browser, *including* proper logout >> support, and UI indications of whether the user is logged in, and with >> what identity. If this is not possible then we must give up on HTTP >> authentication (for the browser anyways). > > Before we give up depression over this, I will add the W3C would like to Heheh, well, I wasn't assuming that the above was impossible. (I think you meant give into depression.) > help the IETF in this effort. The main issue holding us back is that there > is no draft scheme that the major browser vendors support right now. Right. This is key. > However, we will try to have this discussion at W3C TPAC on Oct 31st (and > thus shortly before Atlanta IETF BoF) to see if we can invoke interest in > this topic again. I guess I should head out there. > In essence, I think most of us agree there just has to be some way for the > browser to create in sort of "chrome pop up" so that whatever happens in > that "chrome pop up for login" gets encrypted and shipped out to the JS, Excellent news! Now we need the browser folks to agree too :) Nico -- From cmhjones@gmail.com Thu Sep 13 11:00: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 1A69C21F8628 for ; Thu, 13 Sep 2012 11:00:58 -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=[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 cTBHGFNYjdxX for ; Thu, 13 Sep 2012 11:00:57 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3721F861A for ; Thu, 13 Sep 2012 11:00:57 -0700 (PDT) Received: by qcac10 with SMTP id c10so2541068qca.31 for ; Thu, 13 Sep 2012 11:00: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=qNzS27fHSLJa2ghxQJ8GCGmw+5JN3fOQKEGZbmbUsmA=; b=o6JtFcOHhCKLtkMm+RHxKt+frcmEpkBcvZ7ZFXFc2m0anng9fLnQkGlRFutXJB33O7 hmMIHvBmv7/iCuE8bVJL/OmM4e7XSipKOk+z2OrOn+vhpLp7Mt2tm4yylVpTpvYQo/JB FEZX0Pp+CWqxoimLyise23DT/OX98taGZOkXV9olwMFVFw2rQ+3qyUhSL50KuwMsy4sT oSKGshQkQ5sCmckOhGW+9RQbzk0sZBvVgOTY21cvtsLJbbiZYjMz+ylR8zPMN8LFsmVk uSaEy644/TtSSgg+mB3C72pc7gA2sIGW1jApQd2vCw4va3uckh7Kfkxr1gPTeC0lhks3 1cWA== MIME-Version: 1.0 Received: by 10.224.217.136 with SMTP id hm8mr1001570qab.81.1347559256837; Thu, 13 Sep 2012 11:00:56 -0700 (PDT) Received: by 10.224.209.196 with HTTP; Thu, 13 Sep 2012 11:00:56 -0700 (PDT) In-Reply-To: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> Date: Thu, 13 Sep 2012 19:00:56 +0100 Message-ID: From: Cameron Jones To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 13 Sep 2012 18:00:58 -0000 On Thu, Sep 13, 2012 at 5:19 PM, Nico Williams wrote: > On Wed, Sep 12, 2012 at 4:46 PM, Yoav Nir wrote: >> On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>>>> >>>>> But let's fix I18N in Basic auth: >>>>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >>>>> >>>> >>>> Why do we need to fix sending your password in the clear? >>> >>> Because it's widely used with TLS and causes real-world interop problems. >> >> Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization. > > Agreed. > Disagree. Facebook, Gmail and banks do not the internet make. There are valid uses for using unsecured BASIC which are not your 1st class websites which everyone is concerned with. The benefits of BASIC are that is is trivial to implement, has existing widespread support in browsers and servers, and can be made 'secure' with TLS. The problem which has been highlighted is that it requires the necessary encoding to be universally applicable. There are CJKV users who use their own language characters as passwords. It would be nice to be able to decode these reliably and then we can just ignore BASIC for ever more and get on to developing more secure methods. > The problems with passwords over forms are not interop ones, they are > security ones: > > - servers store hashes that are relatively easy to steal and then > brute-force with offline dictionary attacks; > > - this method (passwords in forms POSTed over HTTPS) is 100% > dependent on a very fallible TLS server PKI; > > - all too often the form is sent over HTTP, not HTTPS, so all too > often there's no real security in the first place. > Existing form-based password authentication is the worst possible situation so anything which stops people needing to use this method is a huge win, including even just an upgrade to BASIC over HTTP as at least the password won't be sent in completely plain-text, although that gain is relatively marginal. >>> The problem with HTTP authentication as of today is that there's no >>> well-defined, interoperable way to stop the browser sending the >>> credentials you entered. Again, this is a real-world problem that stops >>> people from using HTTP auth in the first place. > 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 This approach does not require producing a heavy new specification for browsers to implement and instead lends the HTML methodology of providing simple, high-level semantics which can be interfaced within the site and applicable to virtually any authentication scheme. Thanks, Cameron Jones From turners@ieca.com Thu Sep 13 12:28:08 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 A76BA21F84D2 for ; Thu, 13 Sep 2012 12:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.362 X-Spam-Level: X-Spam-Status: No, score=-101.362 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRYCV1JWA0Vz for ; Thu, 13 Sep 2012 12:28:08 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.82.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE3021F84D1 for ; Thu, 13 Sep 2012 12:28:08 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id BB2CA7D499A3; Thu, 13 Sep 2012 14:28:07 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id A271F7D49963 for ; Thu, 13 Sep 2012 14:28:07 -0500 (CDT) Received: from [108.18.174.220] (port=57257 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TCF55-0001H1-11 for http-auth@ietf.org; Thu, 13 Sep 2012 14:28:07 -0500 Message-ID: <505233C6.1010000@ieca.com> Date: Thu, 13 Sep 2012 15:28:06 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:57257 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [http-auth] drafty http-auth wg charter 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, 13 Sep 2012 19:28:08 -0000 I'm glad to see there's some interest in an http-auth BOF. With the deadlines fast approaching, I'd like jump start the charter discussions by providing a drafty wg charter. Feel free to use this or not. spt -------- HTTP authentication [ref] is currently used for user authentication by some web sites. While form-based user authentication is currently much more commonly used, there is utility in providing better documentation for existing HTTP user authentication schemes that are in use, and for documenting experimental HTTP user authentication schemes that might offer security benefits for future uses. The httpbis WG recently issued a call for proposals [ref] for HTTP authentication schemes as part of its work in further developing HTTP, including work on HTTP/2.0. While a number of proposals were made, [ref] there is at present no consensus to adopt any of those as standards-track work items within the httpbis WG. The http-auth WG will develop a set of informational or experimental RFCs for HTTP user authentication schemes that could, following experimentation, be widely adopted as standards-track schemes for HTTP user authentication. All schemes to be developed in the http-auth WG must be usable with the existing HTTP authentication framework, [ref] or with evolutions of that framework as developed in the httpbis WG. That is, the evolution of the HTTP authentication framework is to be done in the httpbis WG and not in the http-auth WG. However, the http-auth WG may document requirements for changes or additions to the HTTP authentication framework and any schemes developed in the http-auth WG that would benefit from such changes or additions to the HTTP authentication framework must document those changes or additions as an inherent part of their specifications. Any such schemes must however also be usable with the existing unmodified HTTP authentication framework. The http-auth WG will work closely with the httpbis and tls WGs and the <> WGs in W3C to ensure that the outcomes from the http-auth WG do not conflict with work done elsewhere. The initial list of work items will be: - <> Adoption of additional work items will require a re-charter. The following are out of scope: - changes to HTTP - changes to TLS - definition of authentication mechanisms that do not work with the current HTTP authentication framework - authentication of devices or components of web services (??) <> Milestones: - <> From bkihara.l@gmail.com Fri Sep 14 08:09:22 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 567C821F8503 for ; Fri, 14 Sep 2012 08:09:22 -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=[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 7EPV7zOaR8EU for ; Fri, 14 Sep 2012 08:09:21 -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 B6F9721F84FD for ; Fri, 14 Sep 2012 08:09:21 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5464579vcb.31 for ; Fri, 14 Sep 2012 08:09:21 -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=q892a6BlxMCNoCLfedNnfCI4GxLejMXWeiRMvOeWjLM=; b=hc9b8+KkHyzgwok2cuoc9Sf727X0oimW2mRN4OVLzXJD+x3UKFjYqZ+DQ/PIC9zd/5 KnetRso6YWHfikS11ybSt72rT2njM332s3FvqhjlpF761XUNVoyRybrJgI1pdo1SrQDX 53b8MduvxwDXLu/ozJmO4QSYUGolvqlhZRqf9lLyhpq6dhGx/HbWzbYe8+66boWMgfN1 7zXcN5qznsMTzYUP2iZgYz/ynfng4cXqy6wC6zkC6JBe+kZ80eU8ydV/ts6sn1wN7oIK boIUBWnncZ5TQ9LJ+9IuMUITf4euHv36TEwXm9WbZmTCrKUhxMj7UJTGXWQssrRKJrv0 oL6w== MIME-Version: 1.0 Received: by 10.58.69.38 with SMTP id b6mr2544942veu.30.1347635360986; Fri, 14 Sep 2012 08:09:20 -0700 (PDT) Received: by 10.58.221.33 with HTTP; Fri, 14 Sep 2012 08:09:20 -0700 (PDT) In-Reply-To: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> Date: Sat, 15 Sep 2012 00:09:20 +0900 Message-ID: From: "KIHARA, Boku" To: Cameron Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 15:09:22 -0000 2012/9/14 Cameron Jones : > The problem which has been highlighted is that it > requires the necessary encoding to be universally applicable. There > are CJKV users who use their own language characters as passwords. It > would be nice to be able to decode these reliably and then we can just > ignore BASIC for ever more and get on to developing more secure > methods. I heard a discussion about i18n of passwords: about Chinese characters (of course used in Japan too), there are many characters that have the same pronunciations so they are input by input method software. Users type sentences in latin characters (such as pinyin and roma-ji) then pick intended characters from candidates. When inputting passwords, typically input method software are disabled and userstype unconverted characters. As a result, passwords become within ascii range. The problem might be more noticeable in non-ascii locales where characters are input directly from keyboards. By the way, I think i18ning passwords in at least CJ locales will cause another problem that conversion process can be vulnerable to shoulder attacks :< Regards, Boku KIHARA From stpeter@stpeter.im Fri Sep 14 08:25: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 0752521F84B8 for ; Fri, 14 Sep 2012 08:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 w-txajhCAXmo for ; Fri, 14 Sep 2012 08:25:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 066B921F84EB for ; Fri, 14 Sep 2012 08:25:24 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 504B6404FF; Fri, 14 Sep 2012 09:26:13 -0600 (MDT) Message-ID: <50534C63.3080006@stpeter.im> Date: Fri, 14 Sep 2012 09:25:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "KIHARA, Boku" References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> 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] http-auth BOF 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, 14 Sep 2012 15:25:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/14/12 9:09 AM, KIHARA, Boku wrote: > 2012/9/14 Cameron Jones : >> The problem which has been highlighted is that it requires the >> necessary encoding to be universally applicable. There are CJKV >> users who use their own language characters as passwords. It >> would be nice to be able to decode these reliably and then we can >> just ignore BASIC for ever more and get on to developing more >> secure methods. > > I heard a discussion about i18n of passwords: about > Chinese characters (of course used in Japan too), there are many > characters that have the same pronunciations so they are input by > input method software. Users type sentences in latin characters > (such as pinyin and roma-ji) then pick intended characters from > candidates. When inputting passwords, typically input method > software are disabled and userstype unconverted characters. As a > result, passwords become within ascii range. The problem might be > more noticeable in non-ascii locales where characters are input > directly from keyboards. Hello Kihara-san, Could you please clarify what you mean by "unconverted characters"? It seems that you mean these are characters from the ASCII range not converted into their CJ equivalents, but I'd like to make sure. > By the way, I think i18ning passwords in at least CJ locales will > cause another problem that conversion process can be vulnerable to > shoulder attacks :< When you say "i18ning passwords", do you mean allowing characters outside the ASCII range? Of course, we like to enable lots of entropy in passwords, so limiting the allowable characters to the ASCII range would be at odds with that desire. By the way, some of these considerations are relevant to SASLprep (RFC 4013) and its proposed replacement (draft-melnikov-precis-saslprepbis), so I hope you will review the latter specification and provide feedback on the precis@ietf.org and kitten@ietf.org lists. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBTTGMACgkQNL8k5A2w/vwhHgCfamVqTgUQEkTF/c9YFqvvsWpX RBUAoNRad2jaSbcXdMz6//6HP4uAzfhv =mVXQ -----END PGP SIGNATURE----- From hhalpin@w3.org Fri Sep 14 08:39:06 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 662DC21F851E for ; Fri, 14 Sep 2012 08:39:06 -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 rJdiz84Ehdcy for ; Fri, 14 Sep 2012 08:39:05 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54021F851C for ; Fri, 14 Sep 2012 08:38:58 -0700 (PDT) Received: from lputeaux-156-14-30-207.w82-127.abo.wanadoo.fr ([82.127.13.207] helo=[192.168.1.28]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TCXyr-0000rf-3R; Fri, 14 Sep 2012 11:38:57 -0400 Message-ID: <50534F8A.4040004@w3.org> Date: Fri, 14 Sep 2012 17:38:50 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Sean Turner References: <505233C6.1010000@ieca.com> In-Reply-To: <505233C6.1010000@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] drafty http-auth wg charter 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, 14 Sep 2012 15:39:06 -0000 On 09/13/2012 09:28 PM, Sean Turner wrote: > I'm glad to see there's some interest in an http-auth BOF. With the > deadlines fast approaching, I'd like jump start the charter > discussions by providing a drafty wg charter. Feel free to use this > or not. > > spt > > -------- > > HTTP authentication [ref] is currently used for user authentication by > some web sites. While form-based user authentication is currently much > more commonly used, there is utility in providing better documentation > for existing HTTP user authentication schemes that are in use, and for > documenting experimental HTTP user authentication schemes that might > offer security benefits for future uses. > > The httpbis WG recently issued a call for proposals [ref] for HTTP > authentication schemes as part of its work in further developing HTTP, > including work on HTTP/2.0. While a number of proposals were made, > [ref] there is at present no consensus to adopt any of those as > standards-track work items within the httpbis WG. > > The http-auth WG will develop a set of informational or experimental > RFCs for HTTP user authentication schemes that could, following > experimentation, be widely adopted as standards-track schemes for HTTP > user authentication. > > All schemes to be developed in the http-auth WG must be usable with > the existing HTTP authentication framework, [ref] or with evolutions > of that framework as developed in the httpbis WG. That is, the > evolution of the HTTP authentication framework is to be done in the > httpbis WG and not in the http-auth WG. > > However, the http-auth WG may document requirements for changes or > additions to the HTTP authentication framework and any schemes > developed in the http-auth WG that would benefit from such changes or > additions to the HTTP authentication framework must document those > changes or additions as an inherent part of their specifications. Any > such schemes must however also be usable with the existing unmodified > HTTP authentication framework. > > The http-auth WG will work closely with the httpbis and tls WGs and > the <> WGs in W3C to ensure that the outcomes from the > http-auth WG do not conflict with work done elsewhere. I'd add in "Web Cryptography WG" (which is doing JS Crypto API work) and say "and possibly other relevant WG", since depending on how this rolls out there may be cross-over with some open needs in other W3C WGs. > > The initial list of work items will be: > > - < the httpbis WG [ref] that survive the BoF>> > > Adoption of additional work items will require a re-charter. > > The following are out of scope: > > - changes to HTTP > - changes to TLS > - definition of authentication mechanisms that do not work with > the current HTTP authentication framework I think this depends on what we mean by framework. Do we mean "strong backwards compatibility"? So we are limiting ourselves to username+passwords strings (basic-cookie) here in HTTP Basic, albeit strongly encrypted and with better character-set support? That seems feasible but would rule out some other options. > - authentication of devices or components of web services (??) > < but maybe "just web sites" is too limiting?>> I'd agree with components of web services, but "authenticating devices" may be too far. Some WGs may want to have HTTP Auth have some relationship with the presence of key material to authenticate that a particular key exists on a particular device, as they are currently doing in the Web Crypto WG. I agree though it can be treacherous (and sketchy) territory. > > Milestones: > > - <> > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From julian.reschke@gmx.de Fri Sep 14 08:39:08 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 0326421F852C for ; Fri, 14 Sep 2012 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.731 X-Spam-Level: X-Spam-Status: No, score=-103.731 tagged_above=-999 required=5 tests=[AWL=-1.132, 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 tbNvXH0SqLya for ; Fri, 14 Sep 2012 08:39:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B490721F851C for ; Fri, 14 Sep 2012 08:39:06 -0700 (PDT) Received: (qmail invoked by alias); 14 Sep 2012 15:39:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 14 Sep 2012 17:39:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18U7vJwDMsU/iN1c7gISZdN7KBRMtVS26RYiaNUXX FhYYdKJl09UjpC Message-ID: <50534F96.5070907@gmx.de> Date: Fri, 14 Sep 2012 17:39:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yoav Nir References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 15:39:08 -0000 On 2012-09-12 23:46, Yoav Nir wrote: > > On Sep 12, 2012, at 10:02 AM, Julian Reschke wrote: >>>> >>>> But let's fix I18N in Basic auth: >>>> http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html >>>> >>> >>> Why do we need to fix sending your password in the clear? >> >> Because it's widely used with TLS and causes real-world interop problems. > > Strange. I never see them. In GMail, Facebook, CNN and bank websites you only see form-based authentication. And those forms work well with internationalization. > ... tools.ietf.org w3.org my company's internal pages ... It's not as nearly widely used as form-based login, but that doesn't mean it's not widely used. Best regards, Julian From cmhjones@gmail.com Fri Sep 14 08:51:04 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 CF11221F851C for ; Fri, 14 Sep 2012 08:51:04 -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=[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 bKBgH5vKNXui for ; Fri, 14 Sep 2012 08:51:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27B3121F84F8 for ; Fri, 14 Sep 2012 08:51:03 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5788991pbb.31 for ; Fri, 14 Sep 2012 08:50: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=GDdKhyFahhbEJnNOD3Uzh/YszyTKtipqS2SH59xf7WM=; b=d3M5LwFskyJyCjhAGUunfLZwiQwoBC0XYJwWWWgkoIAR7TEGTJumtif7r44ALxMrmi ENP23M72znZowDsRLTbicKplgb0TAxWU+oJVfUDOAejKFrGfPjoROGfcWcIs+cugR/j5 G31Ah4gGhTri2TcxWzwtXSxgA+qdbBIrMGdaulVvvaBC8wUhsyKtQ67HieB5nvlRf8Ss zt3wOgq/RVigohYN7oD+ZMseSEBJYBBVt05TMBlDBQJVxno3JlS713RBRVTPGvect5qK 2Si2OeWZi3YxAcfk9aJbP/o2g0xQHb8IrYCymNU8Zks0VH3Kss6cYh/TTIffpIYRnNxb HI7A== MIME-Version: 1.0 Received: by 10.66.89.6 with SMTP id bk6mr4476610pab.81.1347637856820; Fri, 14 Sep 2012 08:50:56 -0700 (PDT) Received: by 10.68.29.40 with HTTP; Fri, 14 Sep 2012 08:50:56 -0700 (PDT) In-Reply-To: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> Date: Fri, 14 Sep 2012 16:50:56 +0100 Message-ID: From: Cameron Jones To: "KIHARA, Boku" Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 15:51:05 -0000 On Fri, Sep 14, 2012 at 4:09 PM, KIHARA, Boku wrote: > 2012/9/14 Cameron Jones : >> The problem which has been highlighted is that it >> requires the necessary encoding to be universally applicable. There >> are CJKV users who use their own language characters as passwords. It >> would be nice to be able to decode these reliably and then we can just >> ignore BASIC for ever more and get on to developing more secure >> methods. > > > I heard a discussion about i18n of passwords: > about Chinese characters (of course used in Japan too), there are many > characters that have the same pronunciations so they are input by > input method software. Users type sentences in latin characters (such as > pinyin and roma-ji) then pick intended characters from candidates. When > inputting passwords, typically input method software are disabled and > userstype unconverted characters. As a result, passwords become within > ascii range. The problem might be more noticeable in non-ascii locales > where characters are input directly from keyboards. > > > By the way, I think i18ning passwords in at least CJ locales will cause > another problem that conversion process can be vulnerable to shoulder > attacks :< > > > Regards, > Boku KIHARA Good points. I don't actually speak (or type) asian languages so identifying them was purely for illustratory purposes. The point i was making was that ASCII-only is a limitation we could do without based on the scope of foreign languages. There do seem to be some hurdles with the application of the charset, partly that it won't be retroactive so there will always some level of need to manage the decoding. I was initially concerned with the potential to use this as an attack vector, but since BASIC is only sending base64 it's not supposed to be a full-proof security method on it's own, only an authentication method, so providing some extra support in this area is an enhancement for error mitigation. I can't see any danger and maybe in future with greater device support for localized character input it may become even more important to have this support. I also forgot to mention that since this thread was about the BoF, i will sadly be unable to make it to Vancouver but i hope that this is one area that can be discussed by those who can. Thanks, Cameron Jones From nico@cryptonector.com Fri Sep 14 09:56: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 C614B21F84FD for ; Fri, 14 Sep 2012 09:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id groc9lHlYC2R for ; Fri, 14 Sep 2012 09:56:33 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 23BCC21F84EA for ; Fri, 14 Sep 2012 09:56:33 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id A7AA1598065 for ; Fri, 14 Sep 2012 09:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=nO/GXo9j2AshmNx0dxiT aUAEknU=; b=fJc5kmPGxMLcA62OKt1GEWjm/+8Gvc32KsJO+t95aDao1NwA6IaC D9WqviLcUq9R0OFGwQ/DjCU9sc8mWEwl7vgZfHNFJPFGWoy3G5KHJBQFDaaNrjHs FFdPBGIEiby/i+Ky4ijgiQolFztObvJJSq1G6bug2jC0yB2O/rQcnWc= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 8BD8359805F for ; Fri, 14 Sep 2012 09:56:32 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5873343pbb.31 for ; Fri, 14 Sep 2012 09:56:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr5651205pbc.164.1347641792098; Fri, 14 Sep 2012 09:56:32 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 14 Sep 2012 09:56:32 -0700 (PDT) In-Reply-To: <505233C6.1010000@ieca.com> References: <505233C6.1010000@ieca.com> Date: Fri, 14 Sep 2012 11:56:32 -0500 Message-ID: From: Nico Williams To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] drafty http-auth wg charter 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, 14 Sep 2012 16:56:33 -0000 On Thu, Sep 13, 2012 at 2:28 PM, Sean Turner wrote: > The httpbis WG recently issued a call for proposals [ref] for HTTP > authentication schemes as part of its work in further developing HTTP, > including work on HTTP/2.0. While a number of proposals were made, [ref] > there is at present no consensus to adopt any of those as standards-track > work items within the httpbis WG. Did I miss the consensus call on this? Or, if there was no consensus call, how was consensus determined? (FWIW, I do believe that call is right, I'm just curious about the process.) > The http-auth WG will develop a set of informational or experimental RFCs > for HTTP user authentication schemes that could, following experimentation, > be widely adopted as standards-track schemes for HTTP user authentication. OK, we are going for experimental only at first. No problem there. > All schemes to be developed in the http-auth WG must be usable with the > existing HTTP authentication framework, [ref] or with evolutions of that > framework as developed in the httpbis WG. That is, the evolution of the HTTP > authentication framework is to be done in the httpbis WG and not in the > http-auth WG. Interesting. > However, the http-auth WG may document requirements for changes or additions > to the HTTP authentication framework and any schemes developed in the > http-auth WG that would benefit from such changes or additions to the HTTP > authentication framework must document those changes or additions as an > inherent part of their specifications. Any such schemes must however also be > usable with the existing unmodified HTTP authentication framework. Sounds like a recipe for very, very slow progress. "Hi, we need this change." "" "no, really, we need this change" . But let's be optimistic, who knows. > The http-auth WG will work closely with the httpbis and tls WGs and the > <> WGs in W3C to ensure that the outcomes from the http-auth WG do > not conflict with work done elsewhere. > > The initial list of work items will be: > > - < the httpbis WG [ref] that survive the BoF>> Ones that don't survive the BoF could still be pursued as individual submissions, no? After all, we're talking about publishing on the Experimental track. Or would the IESG be encouraged to reject publication of any documents that did not survive the BoF? > Adoption of additional work items will require a re-charter. This is always implied. > The following are out of scope: > > - changes to HTTP What about: - new values for WWW-Authenticate header (which would adhere to the current standard, of course) - new status codes? > - changes to TLS Certainly we don't want to touch TLS, but then, for proposals like OBC we might. > - definition of authentication mechanisms that do not work with > the current HTTP authentication framework That can be a tough call. Does my RESTauth proposal work within the current framework? It uses WWW-Authenticate properly, so I'd say "yes", but it also is RESTful, so maybe "no". I'm at least somewhat concerned by this particular item in the out-of-scope list! > - authentication of devices or components of web services (??) > < but maybe "just web sites" is too limiting?>> Why rule this out of scope _now_? Why not wait and see whether any proposals in that vein are too complex or something? Is it because of possible impact on browser UIs? But look, this item rules out so much potential improvement that I would lose almost all interest as a participant. No, I strongly object to this item on the out-of-scope list! Nico -- From julian.reschke@gmx.de Fri Sep 14 10:00: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 1CA4F21F8533 for ; Fri, 14 Sep 2012 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 rp7f-XFmbqwn for ; Fri, 14 Sep 2012 10:00:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0301221F851A for ; Fri, 14 Sep 2012 10:00:15 -0700 (PDT) Received: (qmail invoked by alias); 14 Sep 2012 17:00:14 -0000 Received: from p54BB2A3C.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.42.60] by mail.gmx.net (mp031) with SMTP; 14 Sep 2012 19:00:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+KeR18lemK1dPn4TQiJmpLuMZfi/Q8isVxyLQLBg UKg+IqJi9+aZMR Message-ID: <50536299.4020702@gmx.de> Date: Fri, 14 Sep 2012 19:00:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nico Williams References: <505233C6.1010000@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] drafty http-auth wg charter 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, 14 Sep 2012 17:00:17 -0000 On 2012-09-14 18:56, Nico Williams wrote: > ...>> The following are out of scope: >> >> - changes to HTTP > > What about: > > - new values for WWW-Authenticate header (which would adhere to the > current standard, of course) > > - new status codes? These does not require changes in HTTP. A status code registry has existed for eons, the registry for auth schemes is part of HTTPbis (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-20.html#rfc.section.2.3). >> - changes to TLS > > Certainly we don't want to touch TLS, but then, for proposals like OBC we might. > >> - definition of authentication mechanisms that do not work with >> the current HTTP authentication framework > > That can be a tough call. Does my RESTauth proposal work within the > current framework? It uses WWW-Authenticate properly, so I'd say > "yes", but it also is RESTful, so maybe "no". I'm at least somewhat > concerned by this particular item in the out-of-scope list! Why would being "restful" (for some value of "restful") be a problem? > ... Best regards, Julian From stephen.farrell@cs.tcd.ie Fri Sep 14 10:00:49 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 E9ED821F853C for ; Fri, 14 Sep 2012 10:00:49 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHLGXuETrLtq for ; Fri, 14 Sep 2012 10:00:49 -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 7359921F851E for ; Fri, 14 Sep 2012 10:00:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E4025171481; Fri, 14 Sep 2012 18:00:43 +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=1347642043; bh=2TK3rJzsceSWYQ 1b89WhwM/q1vn8hOqu1/BZ1FDZ19k=; b=eGDQwyMl5Wfo+SPKpCwVU+xu5jVMqx R7L20Y5Rg4jC9+VknonpzHhPNzt6gzDLMEKIAoD4I/Ryj2YSCePG8A6LE6IY5Xrc hUK/+whewhLpqLCNHMHob1eHT/9Suc/1cUXHi6pcY3a3ZHIk46MJbenZAtrqVplB VHVes0WjFxgszVoMXfjOzRKe/vHskjrNqRTlOrNI51VzPYuu7N7DlPLKM3rQEc5V KlPczIRRwknZu7ZuLFkEKLqEemsDA/tySv8LM2RlmYN5xD9YB7WtlCYRSG9PqKqc QnTfF/28+ZxrJAuW4otf7k1ib6i0pjTrnGb48b20MwRQFU49oN/wTR3g== 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 tuVZLRCRhQsw; Fri, 14 Sep 2012 18:00:43 +0100 (IST) Received: from [IPv6:2001:770:10:203:7557:48ca:2808:7731] (unknown [IPv6:2001:770:10:203:7557:48ca:2808:7731]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8597217147C; Fri, 14 Sep 2012 18:00:43 +0100 (IST) Message-ID: <505362BB.7050600@cs.tcd.ie> Date: Fri, 14 Sep 2012 18:00:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Nico Williams References: <505233C6.1010000@ieca.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] drafty http-auth wg charter 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, 14 Sep 2012 17:00:50 -0000 On 09/14/2012 05:56 PM, Nico Williams wrote: > On Thu, Sep 13, 2012 at 2:28 PM, Sean Turner wrote: >> > The httpbis WG recently issued a call for proposals [ref] for HTTP >> > authentication schemes as part of its work in further developing HTTP, >> > including work on HTTP/2.0. While a number of proposals were made, [ref] >> > there is at present no consensus to adopt any of those as standards-track >> > work items within the httpbis WG. > Did I miss the consensus call on this? Or, if there was no consensus > call, how was consensus determined? (FWIW, I do believe that call is > right, I'm just curious about the process.) I'd have to check the httpbis list, but Mark (httpbis wg chair) called it out in Vancouver and I guess confirmed it on the list, at least via minutes. As you say, he made the right call, there was very clearly no consensus to adopt any of 'em, much as I'd rather the outcome had been different. S. From nico@cryptonector.com Fri Sep 14 11:06:22 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 6714F21F84DF for ; Fri, 14 Sep 2012 11:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCR7AHcSnRor for ; Fri, 14 Sep 2012 11:06:21 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D663B21F84D5 for ; Fri, 14 Sep 2012 11:06:21 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 13AB91F0087 for ; Fri, 14 Sep 2012 11:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=15eZybxHdnNR2gVHGZ6q f0wlobg=; b=NKipKz8LDzfndr6EgRYp5SnoaJIPOSTzHl2MqC75ldGzsApx0g4i 1q73NPrDtLbmfeQGabz53pOozs8Ww5O1bzw0HiqQ2TVanFYkHcS5ynfjZOKj3uOz iR6bDxrhokC5vfi2j5rPVP9pHaYg4E9KD/ABUySmHGiMB9hZuNaFMOY= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id D13B91F0085 for ; Fri, 14 Sep 2012 11:06:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5958742pbb.31 for ; Fri, 14 Sep 2012 11:06:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.83.166 with SMTP id r6mr5124990pay.25.1347645980523; Fri, 14 Sep 2012 11:06:20 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Fri, 14 Sep 2012 11:06:20 -0700 (PDT) In-Reply-To: <50536299.4020702@gmx.de> References: <505233C6.1010000@ieca.com> <50536299.4020702@gmx.de> Date: Fri, 14 Sep 2012 13:06:20 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] drafty http-auth wg charter 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, 14 Sep 2012 18:06:22 -0000 On Fri, Sep 14, 2012 at 12:00 PM, Julian Reschke wrote: > On 2012-09-14 18:56, Nico Williams wrote: >>> - definition of authentication mechanisms that do not work with >>> the current HTTP authentication framework >> >> >> That can be a tough call. Does my RESTauth proposal work within the >> current framework? It uses WWW-Authenticate properly, so I'd say >> "yes", but it also is RESTful, so maybe "no". I'm at least somewhat >> concerned by this particular item in the out-of-scope list! > > > Why would being "restful" (for some value of "restful") be a problem? Because then it's not really an "HTTP authentication scheme" because technically speaking it's using HTTP properly as a transport, so it's "above" HTTP as far as on-the-wire layers go. None of the existing HTTP authentication schemes have this property. (But then, also, none handle multi-legged authentication, and multi-legged authentication exchanges in the traditional DIGEST and Basic approach would be somewhat strange.) Nico -- From cmhjones@gmail.com Fri Sep 14 11:09:47 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 3655621F84DF for ; Fri, 14 Sep 2012 11:09:47 -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=[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 CThIZs+pL+9D for ; Fri, 14 Sep 2012 11:09:46 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9FA921F84D5 for ; Fri, 14 Sep 2012 11:09:46 -0700 (PDT) Received: by dadf8 with SMTP id f8so2578735dad.31 for ; Fri, 14 Sep 2012 11:09:46 -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=pc64Vuy5+rJcRShJFOC97cWNiATf9S16+p3/bdOzqkA=; b=ZrJl3a6WXM7V8VLi8Vpy9fVZIj7xsgc7lCKsNviraf4SDhCEHiXXR93QG2iMa660gB 9fYMa+8dYXyL1m6Mhkxc0zDic+4aB6GwasJikBmsg9VtxJOurKNd0VSKKZhX8Z2fw7Gm yQIqITOWKq6/P/l8ZHoZ16T8V+LBK6Qtg2xpvo7htp3vbIRfAm29SeA7EdTQo/5w7UF9 bsdmucxsIkSQqvCCgwrmY+uAPNI9sn3DAlEyUiVDMaczohJZj1zRvwkJtm5gkxRsrv3K 5pa8HIaeNVFDvR6HexSiDa8NFjbkrH6jdMDHcM9txLWMI8Vl7DVeN6tiEmNNJUcVLcRc oFLg== MIME-Version: 1.0 Received: by 10.68.197.9 with SMTP id iq9mr6212610pbc.17.1347646186303; Fri, 14 Sep 2012 11:09:46 -0700 (PDT) Received: by 10.68.29.40 with HTTP; Fri, 14 Sep 2012 11:09:46 -0700 (PDT) In-Reply-To: References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> Date: Fri, 14 Sep 2012 19:09:46 +0100 Message-ID: From: Cameron Jones To: "KIHARA, Boku" Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 18:09:47 -0000 On Fri, Sep 14, 2012 at 4:50 PM, Cameron Jones wrote: > > I also forgot to mention that since this thread was about the BoF, i > will sadly be unable to make it to Vancouver but i hope that this is > one area that can be discussed by those who can. > I misread the reference to Vancouver as the suggested location for the BoF, so perhaps i may make it if\when\where the BoF takes place (i don't make it down from the Scottish glens and across the English channel much these days, lest the Atlantic and the Canadian prairies :) Thanks, Cameron Jones From stpeter@stpeter.im Fri Sep 14 11:18:09 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 C98F321F853E for ; Fri, 14 Sep 2012 11:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 ql0RK8j1QtSe for ; Fri, 14 Sep 2012 11:18:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1587921F853C for ; Fri, 14 Sep 2012 11:18:08 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EE85840D96; Fri, 14 Sep 2012 12:18:56 -0600 (MDT) Message-ID: <505374DE.3080004@stpeter.im> Date: Fri, 14 Sep 2012 12:18:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Cameron Jones References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> 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] http-auth BOF 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, 14 Sep 2012 18:18:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/14/12 12:09 PM, Cameron Jones wrote: > On Fri, Sep 14, 2012 at 4:50 PM, Cameron Jones > wrote: >> >> I also forgot to mention that since this thread was about the >> BoF, i will sadly be unable to make it to Vancouver but i hope >> that this is one area that can be discussed by those who can. >> > > I misread the reference to Vancouver as the suggested location for > the BoF, so perhaps i may make it if\when\where the BoF takes place > (i don't make it down from the Scottish glens and across the > English channel much these days, lest the Atlantic and the Canadian > prairies :) If approved, the proposed BoF will take place at IETF 85 in Atlanta (November 4 - 9, 2012), although remote participation will be possible as well. http://www.ietf.org/meeting/85/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBTdN4ACgkQNL8k5A2w/vwDTwCfSLhZwvXJKmjZDbu21idK6DvT /zgAnAuuJVDmE/Z9zX5gEnq8FsKldaaq =TC9Z -----END PGP SIGNATURE----- From cmhjones@gmail.com Fri Sep 14 11:21:35 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 EC86B21F853C for ; Fri, 14 Sep 2012 11:21:34 -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=[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 HeR+rZw3VPij for ; Fri, 14 Sep 2012 11:21:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1ECC21F8540 for ; Fri, 14 Sep 2012 11:21:33 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5976583pbb.31 for ; Fri, 14 Sep 2012 11:21:33 -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=Fzuo5/tk06VapO3M2wrFxKQA0lzs+o9gHaqm+PHoxfQ=; b=l00XKMFCVNM9lJaGMipO9FIU6Gy+z1cg/nyWb5m0V40xK9cfkp2ggDJI+f3zfQrVmU /NwClDGH7DBDgYTuR5h0mF08R0hYOQG9iYkY/4NmIksvP8HOcf2OjW0UzKLFg9kuKHK8 xM1wb9971mIaxLMZoBB/Gt139sl6FRn7NtkSHzhVwws1za+7lcF7dNfackFnwaN2v7ar hRdttRx/X7FoG4Otp3YQSZxwoQZV/erioaxExhtt/bOM17CHGJp3ZFNArF3Vo0SJLD0f Cwy5qZJW1cF/2g9QfngMZ9y0Cfl/oDyMA+6ZxjVuEH7zTwufCQwWApjP1Eyz3iYdzaWI e9Sw== MIME-Version: 1.0 Received: by 10.68.130.201 with SMTP id og9mr6187496pbb.12.1347646893177; Fri, 14 Sep 2012 11:21:33 -0700 (PDT) Received: by 10.68.29.40 with HTTP; Fri, 14 Sep 2012 11:21:33 -0700 (PDT) In-Reply-To: <505374DE.3080004@stpeter.im> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <505374DE.3080004@stpeter.im> Date: Fri, 14 Sep 2012 19:21:33 +0100 Message-ID: From: Cameron Jones To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 18:21:35 -0000 On Fri, Sep 14, 2012 at 7:18 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/14/12 12:09 PM, Cameron Jones wrote: >> On Fri, Sep 14, 2012 at 4:50 PM, Cameron Jones >> wrote: >>> >>> I also forgot to mention that since this thread was about the >>> BoF, i will sadly be unable to make it to Vancouver but i hope >>> that this is one area that can be discussed by those who can. >>> >> >> I misread the reference to Vancouver as the suggested location for >> the BoF, so perhaps i may make it if\when\where the BoF takes place >> (i don't make it down from the Scottish glens and across the >> English channel much these days, lest the Atlantic and the Canadian >> prairies :) > > If approved, the proposed BoF will take place at IETF 85 in Atlanta > (November 4 - 9, 2012), although remote participation will be possible > as well. > > http://www.ietf.org/meeting/85/ > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > Good to know, thanks! Cameron Jones From bkihara.l@gmail.com Fri Sep 14 11:35:44 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 3596121F8569 for ; Fri, 14 Sep 2012 11:35:44 -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=[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 5WO0c-Z-ZmCX for ; Fri, 14 Sep 2012 11:35:43 -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 37F3621F854E for ; Fri, 14 Sep 2012 11:35:43 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5730200vcb.31 for ; Fri, 14 Sep 2012 11:35:42 -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=NvrvmDFFZOatDBr9XX0c4wESMbXftodAbJon/q/nGO0=; b=p+aoswQzqH0C/1KZGNwXoTHBKuVdCvTlOAywFav0unsWGzdWSsqzTna4bqg6BngWLT LZ3UQA5bPwMycKh0h/Kd3iR7Mch11KkL4o0woU5vEo9hzVqZuwTnIGQim5y2Sdw3GgU3 vvER8QCwR2TqYIJQHIQF7yUD1ItDtOLpd6LQpT1sCSUVACaWfdydbAr7tTeCorUkdaDf 2IOvgVS6pu3zUaUKomCaVgY24BNltzpV6GjJ1H1gN6IMtlyacQmByJKOqi1yExrcfvtg Si2PSJetZ8V+5y8fsTJ5cAdqHcUySIE+67yF5/qNVAm2H82wc+LTZGaeY9bpMCpm8YWk JkUA== MIME-Version: 1.0 Received: by 10.52.32.233 with SMTP id m9mr21539vdi.88.1347647741837; Fri, 14 Sep 2012 11:35:41 -0700 (PDT) Received: by 10.58.221.33 with HTTP; Fri, 14 Sep 2012 11:35:41 -0700 (PDT) In-Reply-To: <50534C63.3080006@stpeter.im> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50534C63.3080006@stpeter.im> Date: Sat, 15 Sep 2012 03:35:41 +0900 Message-ID: From: "KIHARA, Boku" To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 14 Sep 2012 18:35:44 -0000 2012/9/15 Peter Saint-Andre : > On 9/14/12 9:09 AM, KIHARA, Boku wrote: >> I heard a discussion about i18n of passwords: about >> Chinese characters (of course used in Japan too), there are many >> characters that have the same pronunciations so they are input by >> input method software. Users type sentences in latin characters >> (such as pinyin and roma-ji) then pick intended characters from >> candidates. When inputting passwords, typically input method >> software are disabled and userstype unconverted characters. As a >> result, passwords become within ascii range. The problem might be >> more noticeable in non-ascii locales where characters are input >> directly from keyboards. > > Hello Kihara-san, > > Could you please clarify what you mean by "unconverted characters"? It > seems that you mean these are characters from the ASCII range not > converted into their CJ equivalents, but I'd like to make sure. Exactly. I meant they are ASCII characters that are not processed by input method software. In Japan, the input process is often called "Kanji Henkan" (Chinese characters conversion) so I used the word. >> By the way, I think i18ning passwords in at least CJ locales will >> cause another problem that conversion process can be vulnerable to >> shoulder attacks :< > > When you say "i18ning passwords", do you mean allowing characters > outside the ASCII range? > > Of course, we like to enable lots of entropy in passwords, so limiting > the allowable characters to the ASCII range would be at odds with that > desire. By all means passwords should become more secure and allowing non-ASCII characters is very good way. I only intended to notice that there may be issues to be solved and I am sorry if my message was misleading. > By the way, some of these considerations are relevant to SASLprep (RFC > 4013) and its proposed replacement > (draft-melnikov-precis-saslprepbis), so I hope you will review the > latter specification and provide feedback on the precis@ietf.org and > kitten@ietf.org lists. :) Sure. I hope my little knowledge can help...:< Regards, Boku KIHARA From duerst@it.aoyama.ac.jp Sun Sep 16 20:31:38 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 A978C21F84F2 for ; Sun, 16 Sep 2012 20:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.745 X-Spam-Level: X-Spam-Status: No, score=-105.745 tagged_above=-999 required=5 tests=[AWL=-4.554, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 bAuqlv4fllzE for ; Sun, 16 Sep 2012 20:31:37 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id AFBB121F846E for ; Sun, 16 Sep 2012 20:31:36 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8H3VQSu013751 for ; Mon, 17 Sep 2012 12:31:28 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 621c_961b_2951dd82_0078_11e2_8268_001d096c5782; Mon, 17 Sep 2012 12:31:26 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35711) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 17 Sep 2012 12:31:26 +0900 Message-ID: <50569984.10301@it.aoyama.ac.jp> Date: Mon, 17 Sep 2012 12:31:16 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "KIHARA, Boku" References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50534C63.3080006@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 17 Sep 2012 03:31:38 -0000 I wanted to make exactly the same comment as Mr. Kihara. To give a simple example, when inputting the character/word "flower", most Japanese would type the four keys 'h', 'a', 'n', 'a', which simply corresponds to the pronunciation of that word, "hana". This is then converted to syllabic writing "ã¯ãª", and from there to the actual character for flower, "花", as it would be used in everyday writing. However, there are other characters that are pronounced "hana", such as "è¯" (a variant character for flower), "é¼»" (nose), and so on. To select the correct character, various keys (space, arrow keys, number keys, return,...) are used. To make sure the right character is selected, the user has to *visually* check (-> shoulder attack) and confirm it. As a result, as Mr. Kihara already explained, these characters are not used for passwords in Japanese. Because the same homophone problem for Han characters applies in Chinese and Korean, the situation is the same there. In terms of entropy, Han characters would indeed contribute a lot, but because they require visual checking when entering, they are in general not suited for passwords. Regards, Martin. On 2012/09/15 3:35, KIHARA, Boku wrote: > 2012/9/15 Peter Saint-Andre: >> On 9/14/12 9:09 AM, KIHARA, Boku wrote: >>> I heard a discussion about i18n of passwords: about >>> Chinese characters (of course used in Japan too), there are many >>> characters that have the same pronunciations so they are input by >>> input method software. Users type sentences in latin characters >>> (such as pinyin and roma-ji) then pick intended characters from >>> candidates. When inputting passwords, typically input method >>> software are disabled and userstype unconverted characters. As a >>> result, passwords become within ascii range. The problem might be >>> more noticeable in non-ascii locales where characters are input >>> directly from keyboards. >> >> Hello Kihara-san, >> >> Could you please clarify what you mean by "unconverted characters"? It >> seems that you mean these are characters from the ASCII range not >> converted into their CJ equivalents, but I'd like to make sure. > > Exactly. I meant they are ASCII characters that are not processed by > input method software. In Japan, the input process is often called > "Kanji Henkan" (Chinese characters conversion) so I used the word. > >>> By the way, I think i18ning passwords in at least CJ locales will >>> cause another problem that conversion process can be vulnerable to >>> shoulder attacks :< >> >> When you say "i18ning passwords", do you mean allowing characters >> outside the ASCII range? >> >> Of course, we like to enable lots of entropy in passwords, so limiting >> the allowable characters to the ASCII range would be at odds with that >> desire. > > By all means passwords should become more secure and allowing non-ASCII > characters is very good way. I only intended to notice that there may be > issues to be solved and I am sorry if my message was misleading. > >> By the way, some of these considerations are relevant to SASLprep (RFC >> 4013) and its proposed replacement >> (draft-melnikov-precis-saslprepbis), so I hope you will review the >> latter specification and provide feedback on the precis@ietf.org and >> kitten@ietf.org lists. :) > > Sure. I hope my little knowledge can help...:< > > Regards, > Boku KIHARA > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nico@cryptonector.com Sun Sep 16 23:53:11 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 CC3E221E8040 for ; Sun, 16 Sep 2012 23:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 4bI7N7CaXvnj for ; Sun, 16 Sep 2012 23:53:10 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AA21E803C for ; Sun, 16 Sep 2012 23:53:10 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 04B66438072 for ; Sun, 16 Sep 2012 23:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=GAZbUQBaBiGFkEPjZaK/4r9haxY=; b=vAkN3tnLD6G bcnMcUDS9w8Fz3lcg/9pEYzQJDF2giR4bRuRENVnq5ZNDQEsPNmj4aeXFwZFy8rR 98L7cUursqMlLMiL9oK4UaR72tJpjJXeazDcfIbMG+axWnhlWdraUXajKt/TN7dA rfSWpcTIcKaEIxGe+A7HM58Udk3tOwa4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id E8FFF43806C for ; Sun, 16 Sep 2012 23:53:09 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so8526235pbb.31 for ; Sun, 16 Sep 2012 23:53:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.34 with SMTP id ib2mr20620728pbc.164.1347864789639; Sun, 16 Sep 2012 23:53:09 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Sun, 16 Sep 2012 23:53:09 -0700 (PDT) In-Reply-To: <50569984.10301@it.aoyama.ac.jp> References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50534C63.3080006@stpeter.im> <50569984.10301@it.aoyama.ac.jp> Date: Mon, 17 Sep 2012 01:53:09 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 17 Sep 2012 06:53:11 -0000 On Sun, Sep 16, 2012 at 10:31 PM, "Martin J. D=C3=BCrst" wrote: > I wanted to make exactly the same comment as Mr. Kihara. Solutions: - require partial echo on for password entry (like on many mobile devices) - require audio feedback (such as sight-impaired users might use) - recommend that passwords be comprised of a sub-set of Unicode that can be input on most devices without visual feedback. IMO partial echo on is the only sufficiently general solution. And it's already the rule, not the exception, in the world of mobile devices. > In terms of entropy, Han characters would indeed contribute a lot, but > because they require visual checking when entering, they are in general n= ot > suited for passwords. The key is total entropy for the whole password, not entropy density. That CJK might use 17 bits more efficiently than ASCII uses 7 (8, really, since we don't try to pack ASCII codepoints more tightly than one per-octet) is not enough. (Of course, UTF-8 is not that efficient.) That CJK speakers might more easily recall high-entropy passwords due to the use of visual memory (say) would be very interesting indeed, but that's not something we'd have an easy time grafting onto users of western scripts. If it turns out that it's easier for users to recall high-entropy passwords with echo on, would we choose to give up on protection against shoulder surfing? I think I would, yes. Nico -- From stpeter@stpeter.im Mon Sep 17 08:43:35 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 5585021F8616 for ; Mon, 17 Sep 2012 08:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yI1qov1zIvZO for ; Mon, 17 Sep 2012 08:43:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2628521F8602 for ; Mon, 17 Sep 2012 08:43:30 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1D03D40D52; Mon, 17 Sep 2012 09:44:28 -0600 (MDT) Message-ID: <50574520.1020409@stpeter.im> Date: Mon, 17 Sep 2012 09:43:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50534C63.3080006@stpeter.im> <50569984.10301@it.aoyama.ac.jp> In-Reply-To: <50569984.10301@it.aoyama.ac.jp> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 17 Sep 2012 15:43:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to you both for the helpful explanation! On 9/16/12 9:31 PM, "Martin J. Dürst" wrote: > I wanted to make exactly the same comment as Mr. Kihara. > > To give a simple example, when inputting the character/word > "flower", most Japanese would type the four keys 'h', 'a', 'n', > 'a', which simply corresponds to the pronunciation of that word, > "hana". This is then converted to syllabic writing "ã¯ãª", and from > there to the actual character for flower, "花", as it would be used > in everyday writing. However, there are other characters that are > pronounced "hana", such as "è¯" (a variant character for flower), " > é¼»" (nose), and so on. To select the correct character, various keys > (space, arrow keys, number keys, return,...) are used. To make sure > the right character is selected, the user has to *visually* check > (-> shoulder attack) and confirm it. > > As a result, as Mr. Kihara already explained, these characters are > not used for passwords in Japanese. Because the same homophone > problem for Han characters applies in Chinese and Korean, the > situation is the same there. > > In terms of entropy, Han characters would indeed contribute a lot, > but because they require visual checking when entering, they are in > general not suited for passwords. > > Regards, Martin. > > On 2012/09/15 3:35, KIHARA, Boku wrote: >> 2012/9/15 Peter Saint-Andre: >>> On 9/14/12 9:09 AM, KIHARA, Boku wrote: >>>> I heard a discussion about i18n of passwords: >>>> about Chinese characters (of course used in Japan too), there >>>> are many characters that have the same pronunciations so they >>>> are input by input method software. Users type sentences in >>>> latin characters (such as pinyin and roma-ji) then pick >>>> intended characters from candidates. When inputting >>>> passwords, typically input method software are disabled and >>>> userstype unconverted characters. As a result, passwords >>>> become within ascii range. The problem might be more >>>> noticeable in non-ascii locales where characters are input >>>> directly from keyboards. >>> >>> Hello Kihara-san, >>> >>> Could you please clarify what you mean by "unconverted >>> characters"? It seems that you mean these are characters from >>> the ASCII range not converted into their CJ equivalents, but >>> I'd like to make sure. >> >> Exactly. I meant they are ASCII characters that are not processed >> by input method software. In Japan, the input process is often >> called "Kanji Henkan" (Chinese characters conversion) so I used >> the word. >> >>>> By the way, I think i18ning passwords in at least CJ locales >>>> will cause another problem that conversion process can be >>>> vulnerable to shoulder attacks :< >>> >>> When you say "i18ning passwords", do you mean allowing >>> characters outside the ASCII range? >>> >>> Of course, we like to enable lots of entropy in passwords, so >>> limiting the allowable characters to the ASCII range would be >>> at odds with that desire. >> >> By all means passwords should become more secure and allowing >> non-ASCII characters is very good way. I only intended to notice >> that there may be issues to be solved and I am sorry if my >> message was misleading. >> >>> By the way, some of these considerations are relevant to >>> SASLprep (RFC 4013) and its proposed replacement >>> (draft-melnikov-precis-saslprepbis), so I hope you will review >>> the latter specification and provide feedback on the >>> precis@ietf.org and kitten@ietf.org lists. :) >> >> Sure. I hope my little knowledge can help...:< >> >> Regards, Boku KIHARA >> _______________________________________________ http-auth mailing >> list http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBXRSAACgkQNL8k5A2w/vxfgQCfQl0TqTIQex9LRc8MpaROTxQ5 T7IAoNN3btWWwZC84ys15thBxPae3Ph8 =EKh/ -----END PGP SIGNATURE----- From duerst@it.aoyama.ac.jp Mon Sep 17 23:51:42 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 1DC0D21E8064 for ; Mon, 17 Sep 2012 23:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.526 X-Spam-Level: X-Spam-Status: No, score=-105.526 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 0vh4o9jax393 for ; Mon, 17 Sep 2012 23:51:41 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3B22311E808E for ; Mon, 17 Sep 2012 23:51:40 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8I6pXrA032505 for ; Tue, 18 Sep 2012 15:51:33 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 22f0_9465_4840c830_015d_11e2_9eca_001d096c566a; Tue, 18 Sep 2012 15:51:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38426) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 18 Sep 2012 15:51:32 +0900 Message-ID: <505819F3.8000001@it.aoyama.ac.jp> Date: Tue, 18 Sep 2012 15:51:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Nico Williams References: <504F451E.6070805@ieca.com> <504F466A.3000203@gmx.de> <5A1492FD-FF4A-4B6A-B95B-A7EA5727BB23@checkpoint.com> <50503370.30109@gmx.de> <50534C63.3080006@stpeter.im> <50569984.10301@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] http-auth BOF 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, 18 Sep 2012 06:51:42 -0000 On 2012/09/17 15:53, Nico Williams wrote: > On Sun, Sep 16, 2012 at 10:31 PM, "Martin J. Dürst" > wrote: >> I wanted to make exactly the same comment as Mr. Kihara. > > Solutions: > > - require partial echo on for password entry (like on many mobile devices) Interesting that this is done on mobile devices. I guess the "over the shoulder" problem may be slightly different for (small) mobile devices than for e.g. PCs with big displays. > - require audio feedback (such as sight-impaired users might use) Except for very special feedback (which I assume exists for sight-impaired users), this won't help. The underlying problem is homophones (a typical English example is "sun" vs. "son"), so pronouncing them doesn't show a difference. > - recommend that passwords be comprised of a sub-set of Unicode that > can be input on most devices without visual feedback. That's a recommendation that's easy to make but difficult to implement. There's no easily defined or definable subset of writing Japanese (or Chinese) that doesn't contain homonyms. > IMO partial echo on is the only sufficiently general solution. And > it's already the rule, not the exception, in the world of mobile > devices. > >> In terms of entropy, Han characters would indeed contribute a lot, but >> because they require visual checking when entering, they are in general not >> suited for passwords. > > The key is total entropy for the whole password, not entropy density. > That CJK might use 17 bits more efficiently than ASCII uses 7 (8, > really, since we don't try to pack ASCII codepoints more tightly than > one per-octet) is not enough. (Of course, UTF-8 is not that > efficient.) That CJK speakers might more easily recall high-entropy > passwords due to the use of visual memory (say) would be very > interesting indeed, but that's not something we'd have an easy time > grafting onto users of western scripts. The problem isn't about easier recall with visual memory. Even without seeing the characters in any way, the average user may be perfectly able to remember whether s/he used the character for "flower" or for "nose" in the password. The problem isn't memory, the problem is to make sure that the right character is input in the password field. For some words, the probability that this happens is quite high. Imagine having "flower garden" as a password. "nose garden" makes much less sense, and so the input conversion engine will select "flower garden" rather than "nose garden" with high probability. But because the input conversion engine will try to use all kinds of information from general language knowledge and previous inputs by the user, the results are never guaranteed. Also, if users are pushed to rely on the "most probable" conversion, that will lead to words and phrases with low entropy. In addition, because past input statistics are shared among applications on the same system, there's some danger that this information may leak. (Similar things may be possible on a mobile device if input prediction is on, for any kind of language.) > If it turns out that it's easier for users to recall high-entropy > passwords with echo on, would we choose to give up on protection > against shoulder surfing? I think I would, yes. The premise doesn't apply. Regards, Martin. From bkihara.l@gmail.com Tue Sep 18 07:10:03 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 4A7D121F8670 for ; Tue, 18 Sep 2012 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 9rKQwVi+H8lQ for ; Tue, 18 Sep 2012 07:10:02 -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 BA94D21F875E for ; Tue, 18 Sep 2012 07:10:02 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so9439622vcb.31 for ; Tue, 18 Sep 2012 07:10:02 -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:cc:content-type :content-transfer-encoding; bh=LtjRQL1i32wZe+NTWZWZwhWBpvd9ar7q6jOjg8M7SS4=; b=ftgW90/4OdtWRaGNFFKSjMNvQp45Z8SXKVkqhEh8QTx0bPiFV6n9gNKv5LznrkwVdI NJMVurHmka4e0aPCBVw85XFNnA1SCNSeX+/CNAaGyqozHL2yb7xg/yt+fjeNfBlUDrT5 Cy7dUxcgvRATAkRxTlgK5XU/qDTK8uLiMgU953kLCCinikXcVze12oUqqteeA/ftHiro jyNOSXHBlt8BQqKqOZAsdxJOReXOduIOU/hCUQT6G9uqLABVKe1hT+/5f9/OhpJhL1lk h0K5jOC9d4OxOX/K8LcduEd34c9b2d4XkPGg4YzxdG7kowrv4OnaVfXD81v98+7IrjqH E+mQ== MIME-Version: 1.0 Received: by 10.58.69.38 with SMTP id b6mr167405veu.30.1347977402133; Tue, 18 Sep 2012 07:10:02 -0700 (PDT) Received: by 10.58.221.33 with HTTP; Tue, 18 Sep 2012 07:10:02 -0700 (PDT) Date: Tue, 18 Sep 2012 23:10:02 +0900 Message-ID: From: "KIHARA, Boku" To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: [http-auth] Problems with passwords in various locales (was Re: http-auth BOF) 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, 18 Sep 2012 14:10:03 -0000 2012/9/18 "Martin J. D=FCrst" : > In addition, because past input statistics are shared among applications = on > the same system, there's some danger that this information may leak. > (Similar things may be possible on a mobile device if input prediction is > on, for any kind of language.) Some problems including the above will be solved by introducing identity managers that input strong and memorable passwords on behalf of users. In normal cases managers input passwords so characters won't seen and conversion histories won't be stored. Of course this does not apply when identity managers are not configured. Protection of identity managers? More problematic... (More frequent conversion, more priority in conversion, more vulnerability...) By the way, current password fields in major systems have strange behavior on input method softwares and characters in (at least) Japanese. They disable input method softwares and force ASCII characters for passwords. However, they also accept pasting the contents of clipboard. As a result, people who use Chinese characters (limited at this moment) may use other text fields or editors as temporary working area. Regards, Boku KIHARA From y.oiwa@aist.go.jp Tue Sep 18 20:29: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 03F1821E8084 for ; Tue, 18 Sep 2012 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeoJbStgpcKk for ; Tue, 18 Sep 2012 20:29:09 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id E947911E80DE for ; Tue, 18 Sep 2012 20:29:08 -0700 (PDT) Received: from mail-vb0-f44.google.com ([209.85.212.44]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUFk8BF5j2N+z2k6IXAqpWljKCA0MKe8a@postini.com; Tue, 18 Sep 2012 20:29:09 PDT Received: by vbbfc26 with SMTP id fc26so702473vbb.31 for ; Tue, 18 Sep 2012 20:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Ytm+FmCYl0I7Qe0Bx8wt/9+p70Abyy+aBJ6yZL7NCVA=; b=kNOHOeHgHpY51IkvAgpvezUYVaL+ocF5w2mVRZ/HDNPwmlMtFk7PTs/GcvPrfAnyqs +W0O7gPgx05lwHXgkB2A/dVVKi9LQotmlAb8Kho0EW+cmPPz8zuW2KsYjTD1CIv/wDna Yci45eWlW1cq9R5YQLzclLToxPIWVTvk8m+jQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Ytm+FmCYl0I7Qe0Bx8wt/9+p70Abyy+aBJ6yZL7NCVA=; b=C1TuEfOBzVTHVKvavGmGSQFUCBiHUsbCB6LKVZsLvDIHnS3NcQ/LYBIJ+OaAxztrSs r1l/+co0yMTHBdqqXuPiwzPs6R1veTJsM2Iw8an0ymQOrp49aRhnIGq3QjW7Cng/SoGe Dmk1H/4nJQuRpLIoq5Gl93jNYci6HjLJh1Eg/EraRQVPRfCrdGyxZVtoy15+1FhpFmeM 1cKM6PsdeaeHbKjVnXSlDP3Z2T8UFIQ6BKoBntSAhVufBs1DzmVNUir5PvPGhWXLfTYM zIebBIaFCshkj1/CKh+jgquxwBjcjq1UckWrjkuoOmS2oTeBoX/E8x7MbF3/2OrXUZ+l vAlw== Received: by 10.52.64.209 with SMTP id q17mr1002895vds.32.1348025347718; Tue, 18 Sep 2012 20:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.179.100 with HTTP; Tue, 18 Sep 2012 20:28:47 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Wed, 19 Sep 2012 12:28:47 +0900 Message-ID: To: "KIHARA, Boku" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm311TPlyGVf2iALJd3Q3qFCJHG78A7ozBdnnCIH4eM3arl4lOQJctbA6kG4NpcEWDFWNZw Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Problems with passwords in various locales (was Re: http-auth BOF) 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: Wed, 19 Sep 2012 03:29:10 -0000 Dear http-auth people, If we completely rely on identity managers, we do not need localized "passwords". Longer ASCII random tokens can provide enough entropy. Localization of passwords means that we should work with human users. # Localization of IDs is important for both cases, of course. The most strong point of passwords is portability: whenever we needed, we can memorize it in our brains, or write it on a small piece of paper (and burn it using lighters after its use: easier and reliable than eliminating contents on harddisks!). For this purpose, we need properly defined semantics for canonicalizations of passwords and IDs. If we have more than two binary representations for a single "human-recognizable" IDs or passwords, the whole authentication systems will not work. Unicode has a lot of messes, and just specifying it "UTF-8" will not solve the problem. We will definitely need to quote precis WG outcomes. P.S. Also, as a Japanese, I may need to clarify some of our needs and situations for Western people: we do *not* have virtually any difficulty on memorizing or recognizing two ideographs of similar sounds in passwords , as far as we generate it by humans ourselves. As western people will not likely to confuse on Q and K for the same sounds, we will never confuse on noses and flowers. # Of course, we may sometimes confuse on similarly-looking # characters written down on papers, as Western people # do in 1-I-l or u-v. The problem on Japanese (and Chinese, possibly) is to input them into computers reliably without visual or other feedbacks. Same sequences of typed keys will produce different sequences of characters from time to time, as IMEs use intelligences to provide the best-possible guesses to optimize the input time. # Imagine if you input ASCII passwords using mobile phones, # where the system "optimizes" and changes the order of characters # appear on key "2" in order of most-frequent use from time to time, # like a-c-A-b-B-C or c-a-A-C-B-b. That is why most Japanese people just use ASCII passwords, even if systems allows ideographs. Japanese has already accustomed to use ASCII characters for passwords. We will still need I18n on authentications, but mainly for the ID side. Situations may be different for Korean-speaking people, as their main characters (hangeuls) can be mapped to fixed sequences on keyboards. ## we Japanese do have some direct input systems for ## ideographs using 2 to 4 strokes for 1 character: ## 3-combinations of 40 keys will provide 64000 possibilities... ## The difficulty of that system is to memorize a key sequence ## for every one of >10000 ideographs to input. 2012/9/18 KIHARA, Boku : > 2012/9/18 "Martin J. D=FCrst" : >> In addition, because past input statistics are shared among applications= on >> the same system, there's some danger that this information may leak. >> (Similar things may be possible on a mobile device if input prediction i= s >> on, for any kind of language.) > > Some problems including the above will be solved by introducing > identity managers that input strong and memorable passwords on > behalf of users. In normal cases managers input passwords so > characters won't seen and conversion histories won't be stored. > Of course this does not apply when identity managers are not > configured. > > Protection of identity managers? More problematic... > (More frequent conversion, more priority in conversion, > more vulnerability...) > > > By the way, current password fields in major systems have strange > behavior on input method softwares and characters in (at least) > Japanese. They disable input method softwares and force ASCII > characters for passwords. However, they also accept pasting > the contents of clipboard. As a result, people who use Chinese > characters (limited at this moment) may use other text fields > or editors as temporary working area. > > Regards, > Boku KIHARA > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --=20 Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From turners@ieca.com Wed Sep 26 10:31: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 6EA6E21F85BB for ; Wed, 26 Sep 2012 10:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chBfAXxXnoT2 for ; Wed, 26 Sep 2012 10:31:58 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.150.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1497521F859B for ; Wed, 26 Sep 2012 10:31:58 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id CBC631C76865D; Wed, 26 Sep 2012 12:31:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id AA03F1C7685C5 for ; Wed, 26 Sep 2012 12:31:53 -0500 (CDT) Received: from [108.18.174.220] (port=60076 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGvSn-0002vd-A0 for http-auth@ietf.org; Wed, 26 Sep 2012 12:31:57 -0500 Message-ID: <50633C0C.5040703@ieca.com> Date: Wed, 26 Sep 2012 13:31:56 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:60076 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [http-auth] BOF Status 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: Wed, 26 Sep 2012 17:31:58 -0000 BOF Status: Approved Three tidbits of information I'd like to share: 1) More than one person on the BOF coordination call (IESG/IAB) asked to keep the bar low to publish. So we should keep this in mind. 2) The big concern was what chance there is for deployment. 3) "-" in BOF/WG names causes problems. We just struck the hyphen so it'll be called httpauth. We'll keep the same mailing list though. Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 folks showing up seem about right? Okay, it's time to develop and agenda and line up presenters. As a start, might I suggest: Agenda Bashing Problem Statement Candidates (and keep this short) Charter hack spt From nico@cryptonector.com Wed Sep 26 11:45:46 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 2E2C421F859E for ; Wed, 26 Sep 2012 11:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yv5dIt6w8BE for ; Wed, 26 Sep 2012 11:45:45 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5021F8595 for ; Wed, 26 Sep 2012 11:45:45 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 3EDF7BC041 for ; Wed, 26 Sep 2012 11:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=m5i3jgODveMmLhB2kJpA ZW8L9hU=; b=vHNfNUo5mZLv7bOeYeW5BhSJXrb4ZzPsgzzgJr6zqmKMCYCQb9ji X780/mUPRPp4NnyPM6LWvg/O6cJSBDIXzRgEIQNsZJgnzN/cB2dgHeKykISO+PM3 D2t7Y9lT7nm4/fzYsoNkDAv8JYngi0pqiEgqOGP1pCqS8ft0I9p69u0= Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 251F2BC033 for ; Wed, 26 Sep 2012 11:45:45 -0700 (PDT) Received: by danh15 with SMTP id h15so191121dan.31 for ; Wed, 26 Sep 2012 11:45:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.90.4 with SMTP id bs4mr3490323pab.3.1348685144821; Wed, 26 Sep 2012 11:45:44 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 26 Sep 2012 11:45:44 -0700 (PDT) In-Reply-To: <50633C0C.5040703@ieca.com> References: <50633C0C.5040703@ieca.com> Date: Wed, 26 Sep 2012 13:45:44 -0500 Message-ID: From: Nico Williams To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] BOF Status 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: Wed, 26 Sep 2012 18:45:46 -0000 On Wed, Sep 26, 2012 at 12:31 PM, Sean Turner wrote: > BOF Status: Approved > > Three tidbits of information I'd like to share: > > 1) More than one person on the BOF coordination call (IESG/IAB) asked to > keep the bar low to publish. So we should keep this in mind. How does this relate to some of the comments I had on the proposed charter? > 2) The big concern was what chance there is for deployment. The chances of deployment in the enterprise are substantially higher than on the Internet, IMO. I say this based on what my peers in the enterprise IT world tell me (they suffer HTTP/Negotiate's pain points, and they badly want to do something about these). On the Internet it all depends on... too many things: - browser support - IdP support - federations > 3) "-" in BOF/WG names causes problems. We just struck the hyphen so it'll > be called httpauth. We'll keep the same mailing list though. Sure. > Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 > folks showing up seem about right? If the date of the BoF is solid I may well fly in. > Okay, it's time to develop and agenda and line up presenters. As a start, > might I suggest: > > Agenda Bashing > Problem Statement > Candidates (and keep this short) > Charter hack Sounds good for a start. I'm not sure that we want to spend too much time on candidates. I'd rather spend time on higher-level aspects of candidates than on details. Nico -- From turners@ieca.com Wed Sep 26 13:06:50 2012 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142C921F8552 for ; Wed, 26 Sep 2012 13:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.067 X-Spam-Level: X-Spam-Status: No, score=-102.067 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjkB54-caHJR for ; Wed, 26 Sep 2012 13:06:49 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.44.20]) by ietfa.amsl.com (Postfix) with ESMTP id 963D021F8592 for ; Wed, 26 Sep 2012 13:06:49 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 4B7733512518C; Wed, 26 Sep 2012 15:06:49 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 399B735125144 for ; Wed, 26 Sep 2012 15:06:49 -0500 (CDT) Received: from [108.18.174.220] (port=60268 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TGxse-0006e7-Rq; Wed, 26 Sep 2012 15:06:49 -0500 Message-ID: <50636057.4050906@ieca.com> Date: Wed, 26 Sep 2012 16:06:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Nico Williams References: <50633C0C.5040703@ieca.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:60268 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: http-auth@ietf.org Subject: Re: [http-auth] BOF Status 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: Wed, 26 Sep 2012 20:06:50 -0000 On 9/26/12 2:45 PM, Nico Williams wrote: > On Wed, Sep 26, 2012 at 12:31 PM, Sean Turner wrote: >> BOF Status: Approved >> >> Three tidbits of information I'd like to share: >> >> 1) More than one person on the BOF coordination call (IESG/IAB) asked to >> keep the bar low to publish. So we should keep this in mind. > > How does this relate to some of the comments I had on the proposed charter? Comments from you and Harry are at the head of the line to get resolved. But, I submitted what I sent to the list. No slight intended it's just that I didn't want to be the one judging whether they ought to be accepted or not. It's time for the chairs to take the reins at this point. >> 2) The big concern was what chance there is for deployment. > > The chances of deployment in the enterprise are substantially higher > than on the Internet, IMO. I say this based on what my peers in the > enterprise IT world tell me (they suffer HTTP/Negotiate's pain points, > and they badly want to do something about these). > > On the Internet it all depends on... too many things: > > - browser support > - IdP support > - federations Agreed. >> 3) "-" in BOF/WG names causes problems. We just struck the hyphen so it'll >> be called httpauth. We'll keep the same mailing list though. > > Sure. > >> Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 >> folks showing up seem about right? > > If the date of the BoF is solid I may well fly in. We ought to know by Oct 12 (he says crossing his fingers). >> Okay, it's time to develop and agenda and line up presenters. As a start, >> might I suggest: >> >> Agenda Bashing >> Problem Statement >> Candidates (and keep this short) >> Charter hack > > Sounds good for a start. I'm not sure that we want to spend too much > time on candidates. I'd rather spend time on higher-level aspects of > candidates than on details. Exactly my thinking. We've seen many of them before. spt From nico@cryptonector.com Wed Sep 26 14:07: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 C528621F85D5 for ; Wed, 26 Sep 2012 14:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q8rhD7zdDMe for ; Wed, 26 Sep 2012 14:07:33 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78621F8592 for ; Wed, 26 Sep 2012 14:07:33 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 0BFB99405E for ; Wed, 26 Sep 2012 14:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6QqhA+XKZdpqeGjfJ6tv +1vVT9g=; b=uyPgIgOfPhOu3P/qvxETBmkKBjPgZbT4rbCcVOowLcTk4rcNSRN/ W0/j8ioDnrIL5NZZHLoHOwTjbFAnoJTLeRLlOP0rN40W+odQRMWQfugLVkuh6H7Q cnfSGusX4SasE9gc1WnJ5w8ijlh+ziR4cdONPtNob1pHE550eg7chZo= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id EA8B09405C for ; Wed, 26 Sep 2012 14:07:32 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so2523091pbb.31 for ; Wed, 26 Sep 2012 14:07:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.41 with SMTP id or9mr5931066pbb.67.1348693652510; Wed, 26 Sep 2012 14:07:32 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Wed, 26 Sep 2012 14:07:32 -0700 (PDT) In-Reply-To: <50636057.4050906@ieca.com> References: <50633C0C.5040703@ieca.com> <50636057.4050906@ieca.com> Date: Wed, 26 Sep 2012 16:07:32 -0500 Message-ID: From: Nico Williams To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] BOF Status 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: Wed, 26 Sep 2012 21:07:33 -0000 On Wed, Sep 26, 2012 at 3:06 PM, Sean Turner wrote: >> If the date of the BoF is solid I may well fly in. > > We ought to know by Oct 12 (he says crossing his fingers). What I meant was: once the date is set, please don't change it. I can't spare a whole week to IETF meetings nowadays, so if the BoF might remotely get rescheduled then I'd rather participate remotely. Nico -- From ynir@checkpoint.com Wed Sep 26 14:41:37 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 427D021F85C3 for ; Wed, 26 Sep 2012 14:41:37 -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 Hm3ECLwgT2om for ; Wed, 26 Sep 2012 14:41:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 547D821F851A for ; Wed, 26 Sep 2012 14:41:35 -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 q8QLfMBo006758; Wed, 26 Sep 2012 23:41:30 +0200 X-CheckPoint: {506375AA-2-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; Wed, 26 Sep 2012 23:41:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 26 Sep 2012 23:41:20 +0200 From: Yoav Nir To: Sean Turner Date: Wed, 26 Sep 2012 23:41:18 +0200 Thread-Topic: [http-auth] BOF Status Thread-Index: Ac2cL6nSlJIAhknzQWW1KGc/8JTJmQ== Message-ID: <89351908-7A74-481C-86AC-19C5BB7F3C26@checkpoint.com> References: <50633C0C.5040703@ieca.com> In-Reply-To: <50633C0C.5040703@ieca.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="Windows-1252" 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 Status 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: Wed, 26 Sep 2012 21:41:37 -0000 Hi Sean On Sep 26, 2012, at 7:31 PM, Sean Turner wrote: > BOF Status: Approved >=20 > Three tidbits of information I'd like to share: >=20 > 1) More than one person on the BOF coordination call (IESG/IAB) asked to= =20 > keep the bar low to publish. So we should keep this in mind. Makes sense. The proposed charter talks about informational and experimenta= l. If the (proposed) WG rejects them, they can get a similar result through= an individual submission or the independent stream. Still, even with a low= bar, we should insist on document quality - readable, understandable, prop= er security considerations, etc. > 2) The big concern was what chance there is for deployment. Yes, and I'm wondering if we're going to have in the room somebody who coul= d talk knowledgeably about this. Ideally she'd say "I work for this bank, a= nd we would deploy a secure HTTP auth method if these requirements were met= ". Failing that, we can make do with "I work for Google, and the UI people = tell me we might use this on GMail if =85". We don't have a lot of bank emp= loyees around, but we do have some Google employees, and some consultants. = If one of them is willing to talk (and maybe even write a requirements draf= t) about this, I think we should spare a slot for them. > 3) "-" in BOF/WG names causes problems. We just struck the hyphen so=20 > it'll be called httpauth. We'll keep the same mailing list though. >=20 > Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100= =20 > folks showing up seem about right? I have a feeling that this would be a repeat of the REPUTE BoF. Fixing HTTP= authentication got about 150 people in the room when Yukata Oiwa held a ba= r BoF. I think we should aim higher. > Okay, it's time to develop and agenda and line up presenters. As a=20 > start, might I suggest: >=20 > Agenda Bashing > Problem Statement > Candidates (and keep this short) > Charter hack Assuming we can't get someone who can talk about UI considerations, this so= unds good to me. Please add websec to the list of conflicts to avoid. Yoav From turners@ieca.com Wed Sep 26 17:23:48 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 9044221F8602 for ; Wed, 26 Sep 2012 17:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yVfEOjtJSfm for ; Wed, 26 Sep 2012 17:23:48 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.66.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1407C21F8557 for ; Wed, 26 Sep 2012 17:23:48 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 63A252B226A55; Wed, 26 Sep 2012 19:23:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 593FD2B226A35 for ; Wed, 26 Sep 2012 19:23:48 -0500 (CDT) Received: from [108.18.174.220] (port=61019 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TH1tL-00021Q-FC; Wed, 26 Sep 2012 19:23:47 -0500 Message-ID: <50639C92.1000701@ieca.com> Date: Wed, 26 Sep 2012 20:23:46 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yoav Nir References: <50633C0C.5040703@ieca.com> <89351908-7A74-481C-86AC-19C5BB7F3C26@checkpoint.com> In-Reply-To: <89351908-7A74-481C-86AC-19C5BB7F3C26@checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:61019 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BOF Status 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, 27 Sep 2012 00:23:48 -0000 On 9/26/12 5:41 PM, Yoav Nir wrote: > Hi Sean > > On Sep 26, 2012, at 7:31 PM, Sean Turner wrote: > >> BOF Status: Approved >> >> Three tidbits of information I'd like to share: >> >> 1) More than one person on the BOF coordination call (IESG/IAB) asked to >> keep the bar low to publish. So we should keep this in mind. > > Makes sense. The proposed charter talks about informational and experimental. If the (proposed) WG rejects them, they can get a similar result through an individual submission or the independent stream. Still, even with a low bar, we should insist on document quality - readable, understandable, proper security considerations, etc. I mean we're not going to let just anybody through ;) So I agree. I also want to avoid an instance where the document authors just bash each other about whether their drafts get over the bar. >> 2) The big concern was what chance there is for deployment. > > Yes, and I'm wondering if we're going to have in the room somebody who could talk knowledgeably about this. Ideally she'd say "I work for this bank, and we would deploy a secure HTTP auth method if these requirements were met". Failing that, we can make do with "I work for Google, and the UI people tell me we might use this on GMail if …". We don't have a lot of bank employees around, but we do have some Google employees, and some consultants. If one of them is willing to talk (and maybe even write a requirements draft) about this, I think we should spare a slot for them. We've ensured there will be no conflicts with any SEC WG or BOF, all of Barry's App WGs (core, httpbis, bybi, imapmove, scim, sieve, urnbis, and websec), and rtcweb. Hopefully, we'll get somebody who make a browser to show up ;) Please feel free to fire around messages to WGs where you think folks might be interested (i.e., do shameless PR). >> 3) "-" in BOF/WG names causes problems. We just struck the hyphen so >> it'll be called httpauth. We'll keep the same mailing list though. >> >> Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 >> folks showing up seem about right? > > I have a feeling that this would be a repeat of the REPUTE BoF. Fixing HTTP authentication got about 150 people in the room when Yukata Oiwa held a bar BoF. I think we should aim higher. Ack I'll up the #. >> Okay, it's time to develop and agenda and line up presenters. As a >> start, might I suggest: >> >> Agenda Bashing >> Problem Statement >> Candidates (and keep this short) >> Charter hack > > Assuming we can't get someone who can talk about UI considerations, this sounds good to me. Please add websec to the list of conflicts to avoid. Done. Like I said feel free to start beating the drum and finding those who are interested. spt From y.oiwa@aist.go.jp Wed Sep 26 18:10: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 E7A2021F8645 for ; Wed, 26 Sep 2012 18:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRD73ukye2XE for ; Wed, 26 Sep 2012 18:10:32 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0238221F8643 for ; Wed, 26 Sep 2012 18:10:31 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUGOnh4qLZB1mYXir3jZdxyKZArKgsCYS@postini.com; Wed, 26 Sep 2012 18:10:32 PDT Received: by iec9 with SMTP id 9so3495754iec.31 for ; Wed, 26 Sep 2012 18:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y+LNMkL2J0jWovPuGBTzrP1c/7ng+j6vr32efq0NHCI=; b=jrUr8AYWeABCgM004pFi/2KSBDxW9xMmtQrP4O8Od2tm4lapV4DlNvqWmMNmuj4yUJ bn3yOKwkbXkR4eIxF7qqcxUQWSTMn2YrZv44gS7pvPgzMKiwjykvL54RVcWJzpR1vrIA Cetgz9oeWrMq+hcCoNm9Tj3AdbjCTZfRDxWPI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Y+LNMkL2J0jWovPuGBTzrP1c/7ng+j6vr32efq0NHCI=; b=Fzjj9WVUotDh8SSyWSNkzSoXBIRCnZbrEIWuo186DFMj7FBVXnKeAQuBKfoN43snGA Op1HollDIbyB1A93i2oXEMySPSVBYZJNESmiwSx21D0b1pKeobwvw/bEAzHhDWOImuJv xyH3+ohLt6iiFyH8cyL6RL3MWVoh2PlQ8Ua6KL9iXT9Mjx9IJrU271MmTTtRNBzen0Nm CLzVIg8vieQ1LcjSy+UELxsKY1nXgkMJbewsdH2cQ1xydEkxhIUtdgX9Ro/+Nm+Q/4eD y/bJ454gNUrrKFmkYY904FFpEEnpkDrJ3ysNsDZS0JI0UKpG3GHfY9r5atWQteJh/vpx snXA== Received: by 10.50.152.231 with SMTP id vb7mr2216361igb.1.1348708230586; Wed, 26 Sep 2012 18:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.90.103 with HTTP; Wed, 26 Sep 2012 18:10:10 -0700 (PDT) In-Reply-To: <50633C0C.5040703@ieca.com> References: <50633C0C.5040703@ieca.com> From: Yutaka OIWA Date: Thu, 27 Sep 2012 10:10:10 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQln+TrsKTmhnlRD3qdzUrNK+RTqBD/yaM4W7tBT89NiEAeoaNzLV3fgHilsLCIX4q3CZ5h4 Cc: http-auth@ietf.org Subject: Re: [http-auth] BOF Status 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, 27 Sep 2012 01:10:33 -0000 Thank you, Sean! Regarding the schedule, anytime is Ok for me because I plan to be in IETF for the whole week. However, knowing the schedule any earlier will contribube for inviting as many people as possible. 2012/9/27 Sean Turner : > BOF Status: Approved > > Three tidbits of information I'd like to share: > > 1) More than one person on the BOF coordination call (IESG/IAB) asked to > keep the bar low to publish. So we should keep this in mind. > > 2) The big concern was what chance there is for deployment. > > 3) "-" in BOF/WG names causes problems. We just struck the hyphen so it'll > be called httpauth. We'll keep the same mailing list though. > > Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 > folks showing up seem about right? > > Okay, it's time to develop and agenda and line up presenters. As a start, > might I suggest: > > Agenda Bashing > Problem Statement > Candidates (and keep this short) > Charter hack > > spt > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From turners@ieca.com Wed Sep 26 18:25: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 793D521F8471 for ; Wed, 26 Sep 2012 18:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJVo4-c8lLsL for ; Wed, 26 Sep 2012 18:25:13 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.126.19]) by ietfa.amsl.com (Postfix) with ESMTP id DCE0521F8464 for ; Wed, 26 Sep 2012 18:25:12 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 1ED222B3028B9; Wed, 26 Sep 2012 20:25:13 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 12ED22B302871 for ; Wed, 26 Sep 2012 20:25:13 -0500 (CDT) Received: from [108.18.174.220] (port=61271 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TH2qm-0001Cy-6B; Wed, 26 Sep 2012 20:25:12 -0500 Message-ID: <5063AAF7.4050401@ieca.com> Date: Wed, 26 Sep 2012 21:25:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yutaka OIWA References: <50633C0C.5040703@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:61271 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: http-auth@ietf.org Subject: Re: [http-auth] BOF Status 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, 27 Sep 2012 01:25:13 -0000 I'll see what I can do about keeping it in place one the schedule is announced. This is usually means everybody puts in their clashes correctly and the ADs don't miss any ;) spt On 9/26/12 9:10 PM, Yutaka OIWA wrote: > Thank you, Sean! > > Regarding the schedule, anytime is Ok for me because > I plan to be in IETF for the whole week. > However, knowing the schedule any earlier will contribube > for inviting as many people as possible. > > > 2012/9/27 Sean Turner : >> BOF Status: Approved >> >> Three tidbits of information I'd like to share: >> >> 1) More than one person on the BOF coordination call (IESG/IAB) asked to >> keep the bar low to publish. So we should keep this in mind. >> >> 2) The big concern was what chance there is for deployment. >> >> 3) "-" in BOF/WG names causes problems. We just struck the hyphen so it'll >> be called httpauth. We'll keep the same mailing list though. >> >> Questions for the chairs/group: Do we need MeetEcho or WebEx? Does ~100 >> folks showing up seem about right? >> >> Okay, it's time to develop and agenda and line up presenters. As a start, >> might I suggest: >> >> Agenda Bashing >> Problem Statement >> Candidates (and keep this short) >> Charter hack >> >> spt >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > > From bkihara.l@gmail.com Thu Sep 27 03:26:46 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 B06C321F868A for ; Thu, 27 Sep 2012 03:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 D18-zm-uwHQK for ; Thu, 27 Sep 2012 03:26:46 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAF721F844F for ; Thu, 27 Sep 2012 03:26:46 -0700 (PDT) Received: by qabj40 with SMTP id j40so1960845qab.10 for ; Thu, 27 Sep 2012 03:26:45 -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=PnSiD4x/w4ElVh6xGQu6Xu8rAK63kSEdgi4q9ywP6mY=; b=QuI1JsVrVWeH6w27mYd1yBV8n/1Ny0l9TvDSRK88jsFA+fAvWRmRiRQig3J0TZPX+m XxkIwxwSa3q+v00jqo9/uHvRAL7cYUmfN3oWtFNGE3xo9BTyyn5mtXqFC8slrWrcwlby Kzyl1bLK4Z67CHto/afGSRvWuEDoEzOpOU+Ps/14eRUUS7Bs3KQAFKyRkGi8BsYbBL3c ClfYao7RAZwFdvrG0/6yNmOB7YYDslN5mvvt9WDeX66vdevWfZnNZBYbXO5qEjfTTSbE XUa+lpusXO7cTuKMAkyMgpywJyYP39iiO0nzRQgnwl2Rp0FRiTMsDUkNFv/EgsEBFsvV WIuw== MIME-Version: 1.0 Received: by 10.229.135.84 with SMTP id m20mr2158248qct.89.1348741605688; Thu, 27 Sep 2012 03:26:45 -0700 (PDT) Received: by 10.49.87.163 with HTTP; Thu, 27 Sep 2012 03:26:45 -0700 (PDT) Date: Thu, 27 Sep 2012 19:26:45 +0900 Message-ID: From: "KIHARA, Boku" To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [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, 27 Sep 2012 10:26:46 -0000 Hello, 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? Regards, Boku Kihara From tom@ritter.vg Thu Sep 27 04:12:34 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 16CF021F86E1 for ; Thu, 27 Sep 2012 04:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tlmMmiPXWHnd for ; Thu, 27 Sep 2012 04:12:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 067AA21F86DA for ; Thu, 27 Sep 2012 04:12:33 -0700 (PDT) Received: by pbbro8 with SMTP id ro8so3477179pbb.31 for ; Thu, 27 Sep 2012 04:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v5Cvr3unuWreLbxpdD6kRYku83IRsf233WykiShdNm0=; b=l7f9QRauxQF1YvINfgPe85uGPAWeffr7ej1ywboH/G6attIk8/F/VEl45pYtX5FRF2 lyeVRByslqNmYeVLJVTn838UGtQPGGjdghyk1lLSnU/0Xae6TTZU2PIxT6oiZlBwevk4 KjF+S5EnMjMpbd4FPtW8VfRGMlYZdvhaBc8Pw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=v5Cvr3unuWreLbxpdD6kRYku83IRsf233WykiShdNm0=; b=NwOGKWrYvauzLyLVu84sIN7DTJCkjdARlAAfmwMu4OXFQkA/SMjNBU5q5Ke8nmZRbg xrM1LPy9KFm8DHMN01tqQKSgGOrybuSL94LfQqReH5HZVSVEQ4myRo5lQgQYJytM04Fg /cTlaTMnhZdESxyAp2zWGh/PxzHmM597iAkp5PYjPtEvvEzMbxmQs/w03ECf7fp68hD1 Oii0dtEJfN0mOVXH7Wv8Zcm3NhHnZ2gr+fwNRoa9hPbk5Dy4vNUwK2SI7H6V+8A98hcl h8bADbKH4N4SBjKmFcZD9YKulEZL2A4EfEIgsRA3otXfhj1fjchMh1v6iEzsk21GvzVn T+Dw== Received: by 10.68.141.46 with SMTP id rl14mr10669388pbb.2.1348744352733; Thu, 27 Sep 2012 04:12:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.208.194 with HTTP; Thu, 27 Sep 2012 04:12:12 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Thu, 27 Sep 2012 07:12:12 -0400 Message-ID: To: "KIHARA, Boku" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQma9F3UxP1zOyytUvSRwG5AvCQ0Bkrtzauq97RmP9HGK4d4hPe/ZbQDvfZ4xCcDNB2a5OsF 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, 27 Sep 2012 11:12:34 -0000 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. -tom