From nobody Mon Jan 2 03:42:24 2017 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 82B37128DF6 for ; Mon, 2 Jan 2017 03:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE6DDD7xzc2h for ; Mon, 2 Jan 2017 03:42:20 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60B0126579 for ; Mon, 2 Jan 2017 03:42:19 -0800 (PST) Received: from airhead.local ([IPv6:2001:980:93a5:1:fd59:a831:6620:1614]) by smtp-cloud3.xs4all.net with ESMTP id TPiE1u0081ikzLt01PiF44; Mon, 02 Jan 2017 12:42:17 +0100 Message-ID: <586A3C94.4090504@openfortress.nl> Date: Mon, 02 Jan 2017 12:42:12 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: http-auth@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: [http-auth] Why is there no SASL support in HTTP? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 11:42:22 -0000 Hello, I've been wondering why HTTP Authentication does not support SASL, but instead chooses independent mechanisms from SASL? Having a pluggable framework that is updated independently from HTTP appears beneficial to me. Also, integration with other systems that do use SASL would be greatly improved. With support for SASL is so many mail clients already, its introduction to HTTP clients may be relatively smooth. I am aware that mechanisms need to store state on the validating side, so the server, which contradicts HTTP design. That may be easily resolved by passing some state back to the client, and making it supply when it continues. For example, digest-based authentication might send back random bytes as state, and hash it with an internal key to form a challenge. When presented with the state and response, the computation can be validated without a need for state on the server. Alternatives to state on the server may also exist -- for instance, a TLS wrapper may provide consistent entropy using RFC 5705. One thing I've been thinking is that SASL EXTERNAL may be a useful addition. Not to actually authenticate, but it could trigger authorisation processes, possibly using another identity and/or triggering the generation of Authorization-Info headers that might relay information (such as identity) to the client at the HTTP layer. If so desired, I am willing to write an I-D for this. Thanks, Rick van Rein (wishing all a properly secured 2017) http://internetwide.org From nobody Tue Jan 3 14:30:33 2017 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 8B02F129A71 for ; Tue, 3 Jan 2017 14:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErojnbspW9d6 for ; Tue, 3 Jan 2017 14:30:30 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C593A129A62 for ; Tue, 3 Jan 2017 14:30:29 -0800 (PST) Received: from [172.31.25.253] (VPN-172-31-25-253.VPN.CMU.LOCAL [172.31.25.253]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v03MUPd8077263 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Jan 2017 17:30:26 -0500 To: http-auth@ietf.org References: <586A3C94.4090504@openfortress.nl> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <8fe83a05-d104-4fee-f483-0ff74e84b80e@andrew.cmu.edu> Date: Tue, 3 Jan 2017 17:30:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <586A3C94.4090504@openfortress.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.3.222117 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NS , __URI_NS_SERVFAIL , __URI_WITH_PATH 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.202 Archived-At: Subject: Re: [http-auth] Why is there no SASL support in HTTP? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:30:31 -0000 Already tried once: https://tools.ietf.org/html/draft-nystrom-http-sasl-12 This effort was before my interest in HTTP so I don't know why it died. On 01/02/2017 06:42 AM, Rick van Rein wrote: > Hello, > > I've been wondering why HTTP Authentication does not support SASL, but > instead chooses independent mechanisms from SASL? > > Having a pluggable framework that is updated independently from HTTP > appears beneficial to me. Also, integration with other systems that do > use SASL would be greatly improved. With support for SASL is so many > mail clients already, its introduction to HTTP clients may be relatively > smooth. > > I am aware that mechanisms need to store state on the validating side, > so the server, which contradicts HTTP design. That may be easily > resolved by passing some state back to the client, and making it supply > when it continues. For example, digest-based authentication might send > back random bytes as state, and hash it with an internal key to form a > challenge. When presented with the state and response, the computation > can be validated without a need for state on the server. > > Alternatives to state on the server may also exist -- for instance, a > TLS wrapper may provide consistent entropy using RFC 5705. > > > One thing I've been thinking is that SASL EXTERNAL may be a useful > addition. Not to actually authenticate, but it could trigger > authorisation processes, possibly using another identity and/or > triggering the generation of Authorization-Info headers that might relay > information (such as identity) to the client at the HTTP layer. > > > If so desired, I am willing to write an I-D for this. > > > Thanks, > > Rick van Rein > (wishing all a properly secured 2017) > http://internetwide.org > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Jan 3 15:05:31 2017 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 594631298A6 for ; Tue, 3 Jan 2017 15:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5GANHvWKUPj for ; Tue, 3 Jan 2017 15:05:28 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D5A12989C for ; Tue, 3 Jan 2017 15:05:28 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v03MtQI6029672 for ; Tue, 3 Jan 2017 18:05:27 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 27rf5bsc2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 03 Jan 2017 18:05:27 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v03N5RPH011812 for ; Tue, 3 Jan 2017 18:05:27 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v03N5Ls7011760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jan 2017 18:05:23 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Tue, 3 Jan 2017 23:05:03 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.158]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 18:05:03 -0500 From: "HANSEN, TONY L" To: "http-auth@ietf.org" Thread-Topic: [http-auth] Why is there no SASL support in HTTP? Thread-Index: AQHSZO1RSepZQ0ifxE6hB+xKODPLpaEnq+uA//+12YA= Date: Tue, 3 Jan 2017 23:05:02 +0000 Message-ID: References: <586A3C94.4090504@openfortress.nl> <8fe83a05-d104-4fee-f483-0ff74e84b80e@andrew.cmu.edu> In-Reply-To: <8fe83a05-d104-4fee-f483-0ff74e84b80e@andrew.cmu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.241.67] Content-Type: text/plain; charset="utf-8" Content-ID: <88276B12C132354781E7E7DA9AF085CF@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701030343 Archived-At: Subject: Re: [http-auth] Why is there no SASL support in HTTP? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 23:05:30 -0000 V2hlbiBBbGV4ZXkgYW5kIEkgd2VyZSB3b3JraW5nIG9uIHRoZSBTQ1JBTSBTSEEtMjU2IFNBU0wg bWVjaGFuaXNtIGFuZCB1c2luZyB0aGF0IGZvciBIVFRQIFNDUkFNIGF1dGhlbnRpY2F0aW9uLCBp dCB3YXMgcHVycG9zZWx5IGRvbmUgaW4gYSB3YXkgdGhhdCBmb2xsb3dlZCBzdGFuZGFyZCBTQVNM IHByYWN0aWNlcyBhbmQgdGhhdCB3b3VsZCBhbGxvdyBhIHN0b2NrIFNBU0wgU0NSQU0gbGlicmFy eSB0byBiZSB1c2VkLiBQbGVhc2UgcmV2aWV3IFJGQyA3ODA0IGFuZCB0aGUgdXNlIG9mIHNpZD0g YW5kIGRhdGE9IHdpdGhpbiB0aGUgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBmcm9tIHRoZSBo ZWFkZXIgYW5kIHN1YnNlcXVlbnQgQXV0aG9yaXphdGlvbiByZXNwb25zZSBmcm9tIHRoZSBjbGll bnQuIFRoZSBzaWQ9IOKAnHNlc3Npb24gaWRlbnRpZmllcuKAnSBpcyB0aGUgYmluZGluZyBtZWNo YW5pc20gdGhhdCBwcmVzZXJ2ZXMgdGhlIHN0YXRlIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgY2xp ZW50LCBhbmQgZGF0YT0gaG9sZHMgdGhlIFNBU0wgcGF5bG9hZC4gVGhpcyBjb3VsZCBlYXNpbHkg Z2VuZXJhbGl6ZSB0byBvdGhlciBTQVNMIG1lY2hhbmlzbXMsIHNvIDx0aGF0PiBwb3J0aW9uIG9m IHRoZSBwcm9ibGVtIGNhbiBiZSBjb25zaWRlcmVkIHJlc29sdmVkLiANCg0KVGhlIG1pc3Npbmcg bGlua3MgYXJlOg0KDQoxKSBhIG1lY2hhbmlzbSBmb3IgU0FTTCBtZWNoYW5pc20gZGlzY292ZXJ5 Lg0KMikgdGhlIHdpbGxpbmduZXNzIGJ5IGNsaWVudCBhbmQgc2VydmVyIGltcGxlbWVudGVycyB0 byBleHRlbmQgdGhpcyBpbnRvIG90aGVyIFNBU0wgbWVjaGFuaXNtcy4NCg0KIzEgY291bGQgYmUg c29sdmVkIGluIGEgc3RyYWlnaHRmb3J3YXJkIGZhc2hpb24uIEJ1dCBJIGRvbuKAmXQgdGhpbmsg dGhlcmXigJlzIGVub3VnaCBpbnRlcmVzdCBjdXJyZW50bHkgZm9yICMyLiBJIGNvbnNpZGVyZWQg d3JpdGluZyBhIGZvbGxvdy11cCB0byBSRkMgNzgwNCB0byBnZW5lcmFsaXplIHRoZSBtZWNoYW5p c20gZm9yIFNBU0wgaW4gZ2VuZXJhbCwgYnV0IGZlbHQgYSBsYWNrIG9mIGVudGh1c2lhc20gYXQg dGhhdCB0aW1lIGZvciBhbnkgYWRkaXRpb25hbCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLg0K DQoJVG9ueSBIYW5zZW4NCg0KT24gMS8zLzE3LCA1OjMwIFBNLCAiaHR0cC1hdXRoIG9uIGJlaGFs ZiBvZiBLZW4gTXVyY2hpc29uIiA8aHR0cC1hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIG11cmNoQGFuZHJldy5jbXUuZWR1PiB3cm90ZToNCg0KICAgIEFscmVhZHkgdHJpZWQgb25j ZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW55c3Ryb20taHR0cC1zYXNsLTEy DQogICAgDQogICAgVGhpcyBlZmZvcnQgd2FzIGJlZm9yZSBteSBpbnRlcmVzdCBpbiBIVFRQIHNv IEkgZG9uJ3Qga25vdyB3aHkgaXQgZGllZC4NCiAgICANCiAgICANCiAgICANCiAgICBPbiAwMS8w Mi8yMDE3IDA2OjQyIEFNLCBSaWNrIHZhbiBSZWluIHdyb3RlOg0KICAgID4gSGVsbG8sDQogICAg Pg0KICAgID4gSSd2ZSBiZWVuIHdvbmRlcmluZyB3aHkgSFRUUCBBdXRoZW50aWNhdGlvbiBkb2Vz IG5vdCBzdXBwb3J0IFNBU0wsIGJ1dA0KICAgID4gaW5zdGVhZCBjaG9vc2VzIGluZGVwZW5kZW50 IG1lY2hhbmlzbXMgZnJvbSBTQVNMPw0KICAgID4NCiAgICA+IEhhdmluZyBhIHBsdWdnYWJsZSBm cmFtZXdvcmsgdGhhdCBpcyB1cGRhdGVkIGluZGVwZW5kZW50bHkgZnJvbSBIVFRQDQogICAgPiBh cHBlYXJzIGJlbmVmaWNpYWwgdG8gbWUuICBBbHNvLCBpbnRlZ3JhdGlvbiB3aXRoIG90aGVyIHN5 c3RlbXMgdGhhdCBkbw0KICAgID4gdXNlIFNBU0wgd291bGQgYmUgZ3JlYXRseSBpbXByb3ZlZC4g IFdpdGggc3VwcG9ydCBmb3IgU0FTTCBpcyBzbyBtYW55DQogICAgPiBtYWlsIGNsaWVudHMgYWxy ZWFkeSwgaXRzIGludHJvZHVjdGlvbiB0byBIVFRQIGNsaWVudHMgbWF5IGJlIHJlbGF0aXZlbHkN CiAgICA+IHNtb290aC4NCiAgICA+DQogICAgPiBJIGFtIGF3YXJlIHRoYXQgbWVjaGFuaXNtcyBu ZWVkIHRvIHN0b3JlIHN0YXRlIG9uIHRoZSB2YWxpZGF0aW5nIHNpZGUsDQogICAgPiBzbyB0aGUg c2VydmVyLCB3aGljaCBjb250cmFkaWN0cyBIVFRQIGRlc2lnbi4gIFRoYXQgbWF5IGJlIGVhc2ls eQ0KICAgID4gcmVzb2x2ZWQgYnkgcGFzc2luZyBzb21lIHN0YXRlIGJhY2sgdG8gdGhlIGNsaWVu dCwgYW5kIG1ha2luZyBpdCBzdXBwbHkNCiAgICA+IHdoZW4gaXQgY29udGludWVzLiAgRm9yIGV4 YW1wbGUsIGRpZ2VzdC1iYXNlZCBhdXRoZW50aWNhdGlvbiBtaWdodCBzZW5kDQogICAgPiBiYWNr IHJhbmRvbSBieXRlcyBhcyBzdGF0ZSwgYW5kIGhhc2ggaXQgd2l0aCBhbiBpbnRlcm5hbCBrZXkg dG8gZm9ybSBhDQogICAgPiBjaGFsbGVuZ2UuICBXaGVuIHByZXNlbnRlZCB3aXRoIHRoZSBzdGF0 ZSBhbmQgcmVzcG9uc2UsIHRoZSBjb21wdXRhdGlvbg0KICAgID4gY2FuIGJlIHZhbGlkYXRlZCB3 aXRob3V0IGEgbmVlZCBmb3Igc3RhdGUgb24gdGhlIHNlcnZlci4NCiAgICA+DQogICAgPiBBbHRl cm5hdGl2ZXMgdG8gc3RhdGUgb24gdGhlIHNlcnZlciBtYXkgYWxzbyBleGlzdCAtLSBmb3IgaW5z dGFuY2UsIGENCiAgICA+IFRMUyB3cmFwcGVyIG1heSBwcm92aWRlIGNvbnNpc3RlbnQgZW50cm9w eSB1c2luZyBSRkMgNTcwNS4NCiAgICA+DQogICAgPg0KICAgID4gT25lIHRoaW5nIEkndmUgYmVl biB0aGlua2luZyBpcyB0aGF0IFNBU0wgRVhURVJOQUwgbWF5IGJlIGEgdXNlZnVsDQogICAgPiBh ZGRpdGlvbi4gIE5vdCB0byBhY3R1YWxseSBhdXRoZW50aWNhdGUsIGJ1dCBpdCBjb3VsZCB0cmln Z2VyDQogICAgPiBhdXRob3Jpc2F0aW9uIHByb2Nlc3NlcywgcG9zc2libHkgdXNpbmcgYW5vdGhl ciBpZGVudGl0eSBhbmQvb3INCiAgICA+IHRyaWdnZXJpbmcgdGhlIGdlbmVyYXRpb24gb2YgQXV0 aG9yaXphdGlvbi1JbmZvIGhlYWRlcnMgdGhhdCBtaWdodCByZWxheQ0KICAgID4gaW5mb3JtYXRp b24gKHN1Y2ggYXMgaWRlbnRpdHkpIHRvIHRoZSBjbGllbnQgYXQgdGhlIEhUVFAgbGF5ZXIuDQog ICAgPg0KICAgID4NCiAgICA+IElmIHNvIGRlc2lyZWQsIEkgYW0gd2lsbGluZyB0byB3cml0ZSBh biBJLUQgZm9yIHRoaXMuDQogICAgPg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+DQogICAg PiBSaWNrIHZhbiBSZWluDQogICAgPiAod2lzaGluZyBhbGwgYSBwcm9wZXJseSBzZWN1cmVkIDIw MTcpDQogICAgPiBodHRwOi8vaW50ZXJuZXR3aWRlLm9yZw0KICAgID4NCiAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBodHRwLWF1dGgg bWFpbGluZyBsaXN0DQogICAgPiBodHRwLWF1dGhAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cC1hdXRoDQogICAgDQogICAgLS0gDQogICAg S2VubmV0aCBNdXJjaGlzb24NCiAgICBQcmluY2lwYWwgU3lzdGVtcyBTb2Z0d2FyZSBFbmdpbmVl cg0KICAgIENhcm5lZ2llIE1lbGxvbiBVbml2ZXJzaXR5DQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBodHRwLWF1dGggbWFpbGlu ZyBsaXN0DQogICAgaHR0cC1hdXRoQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9odHRwLWF1dGgNCiAgICANCg0K From nobody Thu Jan 5 01:16:48 2017 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 B168B129439 for ; Thu, 5 Jan 2017 01:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfSNXovuP421 for ; Thu, 5 Jan 2017 01:16:44 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB17128E19 for ; Thu, 5 Jan 2017 01:16:43 -0800 (PST) Received: from airhead.local ([IPv6:2001:980:93a5:1:3da7:3bf8:9c50:2ca7]) by smtp-cloud6.xs4all.net with ESMTP id UZGe1u0080KuCFd01ZGfTq; Thu, 05 Jan 2017 10:16:41 +0100 Message-ID: <586E0EF5.5080108@openfortress.nl> Date: Thu, 05 Jan 2017 10:16:37 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: http-auth@ietf.org References: <586A3C94.4090504@openfortress.nl> <8fe83a05-d104-4fee-f483-0ff74e84b80e@andrew.cmu.edu> <586E0E90.7030902@openfortress.nl> In-Reply-To: <586E0E90.7030902@openfortress.nl> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [http-auth] Why is there no SASL support in HTTP? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:16:46 -0000 Hi Tony, Thanks a lot! > 1) a mechanism for SASL mechanism discovery. > 2) the willingness by client and server implementers to extend this into other SASL mechanisms. > > #1 could be solved in a straightforward fashion. But I don’t think there’s enough interest currently for #2. I have a very concrete place where I want it, and it doesn't have the usual chicken / egg problem: The Nginx proxy has a "Auth Request" mechanism where authn / authz can be performed via a HTTP call to a backend; status codes 401, 403 or 2xx are interpreted and output header values may be harvested. A similar mechanism could be used for a SASL backend. This could directly integrate with its backends for POP3, IMAP, SMTP and (3rd party) XMPP. Although there's no direct need to standardise it for this internal purpose, it may be the best way to go. That may turn out to be a useful bootstrapping path, making it flow into closed systems and gradually spreading out. Wishful thinking? There's no way to know but to try... What you are stating is mostly pragmatic, and the need to build up enthousiasm for writing it down. I think HTTP SASL is well worth the effort, and at least allow HTTP programmers to get away from the in-site coding of password logic, and adopt more mechanisms. So I now feel encouraged to write it down. Thanks! -Rick From nobody Fri Jan 6 14:12:22 2017 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B13E126BF7; Fri, 6 Jan 2017 14:12:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148374073752.17474.14854827129235366898.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 14:12:17 -0800 Archived-At: Cc: draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org, http-auth@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [http-auth] Document Action: 'Mutual Authentication Protocol for HTTP' to Experimental RFC (draft-ietf-httpauth-mutual-11.txt) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:12:17 -0000 The IESG has approved the following document: - 'Mutual Authentication Protocol for HTTP' (draft-ietf-httpauth-mutual-11.txt) as Experimental RFC This document is the product of the Hypertext Transfer Protocol Authentication Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ Technical Summary This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. Working Group Summary This document is one of the experimental documents submitted to the HTTP-Auth working group. With version -8 it is the consensus of the HTTP-Auth working group that this document is fit to be published as an experimental RFC. Document Quality The proposed mutual authentication method has been reviewed by a fair number of participants. There is at least one known implementation of this protocol. The authors declared 2 IPRs: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-httpauth-mutual Personnel Shepherd: Rifaat Shekh-Yusef Area Director: Kathleen Moriarty IANA Note This draft establishes two registries that require expert review per RFC5226. A registry for HTTP Mutual authentication algorithms and A registry for HTTP Mutual authentication host validation methods From nobody Wed Jan 25 17:30:13 2017 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 5D669129457; Wed, 25 Jan 2017 17:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J56cfSCKiTNs; Wed, 25 Jan 2017 17:29:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF5412944E; Wed, 25 Jan 2017 17:29:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A60D4B80F7D; Wed, 25 Jan 2017 17:29:47 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170126012947.A60D4B80F7D@rfc-editor.org> Date: Wed, 25 Jan 2017 17:29:47 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, http-auth@ietf.org, rfc-editor@rfc-editor.org Subject: [http-auth] RFC 8053 on HTTP Authentication Extensions for Interactive Clients X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 01:30:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8053 Title: HTTP Authentication Extensions for Interactive Clients Author: Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku Status: Experimental Stream: IETF Date: January 2017 Mailbox: y.oiwa@aist.go.jp, h-watanabe@aist.go.jp, takagi.hiromitsu@aist.go.jp, maeda@lepidum.co.jp, hayashi@lepidum.co.jp, mutual-work@ioku.org Pages: 28 Characters: 62530 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-httpauth-extension-09.txt URL: https://www.rfc-editor.org/info/rfc8053 DOI: 10.17487/RFC8053 This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication. This document is a product of the Hypertext Transfer Protocol Authentication Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC