Re: [http-auth] Why is there no SASL support in HTTP?

"HANSEN, TONY L" <tony@att.com> Tue, 03 January 2017 23:05 UTC

Return-Path: <tony@att.com>
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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietf.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. (8.16.0.17/8.16.0.17) with SMTP id v03MtQI6029672 for <http-auth@ietf.org>; 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 <http-auth@ietf.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 <http-auth@ietf.org>; 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 <http-auth@ietf.org>; 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 <http-auth@ietf.org>; 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" <tony@att.com>
To: "http-auth@ietf.org" <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: <ECB0DAA2-0297-4AAF-AD77-42048403E884@att.com>
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: <https://mailarchive.ietf.org/arch/msg/http-auth/8fTaJIJu4myR4Xq_wZEcq7zRSss>
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 <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.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" <http-auth-bounces@ietf.org on behalf of murch@andrew.cmu.edu> 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
    > http-auth@ietf.org
    > https://www.ietf.org/mailman/listinfo/http-auth
    
    -- 
    Kenneth Murchison
    Principal Systems Software Engineer
    Carnegie Mellon University
    
    _______________________________________________
    http-auth mailing list
    http-auth@ietf.org
    https://www.ietf.org/mailman/listinfo/http-auth