Re: [http-auth] Why is there no SASL support in HTTP?
"HANSEN, TONY L" <email@example.com> Tue, 03 January 2017 23:05 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594631298A6 for <firstname.lastname@example.org>; Tue, 3 Jan 2017 15:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5GANHvWKUPj for <email@example.com>; Tue, 3 Jan 2017 15:05:28 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [126.96.36.199]) (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 <firstname.lastname@example.org>; 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. (188.8.131.52/184.108.40.206) with SMTP id v03MtQI6029672 for <email@example.com>; Tue, 3 Jan 2017 18:05:27 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [220.127.116.11]) by m0049462.ppops.net-00191d01. with ESMTP id 27rf5bsc2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <firstname.lastname@example.org>; 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 <email@example.com>; Tue, 3 Jan 2017 18:05:27 -0500
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [18.104.22.168]) 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 <firstname.lastname@example.org>; Tue, 3 Jan 2017 18:05:23 -0500
Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [22.214.171.124]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for <email@example.com>; Tue, 3 Jan 2017 23:05:03 GMT
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.158]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([126.96.36.199]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 18:05:03 -0500
From: "HANSEN, TONY L" <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>
Thread-Topic: [http-auth] Why is there no SASL support in HTTP?
Date: Tue, 3 Jan 2017 23:05:02 +0000
References: <586A3C94.email@example.com> <firstname.lastname@example.org>
Content-Type: text/plain; charset="utf-8"
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
Subject: Re: [http-auth] Why is there no SASL support in HTTP?
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 23:05:30 -0000
When Alexey and I were working on the SCRAM SHA-256 SASL mechanism and using that for HTTP SCRAM authentication, it was purposely done in a way that followed standard SASL practices and that would allow a stock SASL SCRAM library to be used. Please review RFC 7804 and the use of sid= and data= within the WWW-Authenticate response from the header and subsequent Authorization response from the client. The sid= “session identifier” is the binding mechanism that preserves the state between the server and client, and data= holds the SASL payload. This could easily generalize to other SASL mechanisms, so <that> portion of the problem can be considered resolved. The missing links are: 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 considered writing a follow-up to RFC 7804 to generalize the mechanism for SASL in general, but felt a lack of enthusiasm at that time for any additional authentication mechanisms. Tony Hansen On 1/3/17, 5:30 PM, "http-auth on behalf of Ken Murchison" <email@example.com on behalf of firstname.lastname@example.org> wrote: 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 > email@example.com > https://www.ietf.org/mailman/listinfo/http-auth -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University _______________________________________________ http-auth mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/http-auth
- [http-auth] Why is there no SASL support in HTTP? Rick van Rein
- Re: [http-auth] Why is there no SASL support in H… Ken Murchison
- Re: [http-auth] Why is there no SASL support in H… HANSEN, TONY L
- Re: [http-auth] Why is there no SASL support in H… Rick van Rein
- Re: [http-auth] Why is there no SASL support in H… Rick van Rein
- Re: [http-auth] Why is there no SASL support in H… Yoav Nir