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

"HANSEN, TONY L" <> Tue, 03 January 2017 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 594631298A6 for <>; Tue, 3 Jan 2017 15:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D5GANHvWKUPj for <>; Tue, 3 Jan 2017 15:05:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3D5A12989C for <>; Tue, 3 Jan 2017 15:05:28 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id v03MtQI6029672 for <>; Tue, 3 Jan 2017 18:05:27 -0500
Received: from ( []) by 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 (localhost []) by (8.14.5/8.14.5) with ESMTP id v03N5RPH011812 for <>; Tue, 3 Jan 2017 18:05:27 -0500
Received: from ( []) by (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 ( []) by (RSA Interceptor) for <>; Tue, 3 Jan 2017 23:05:03 GMT
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 18:05:03 -0500
From: "HANSEN, TONY L" <>
To: "" <>
Thread-Topic: [http-auth] Why is there no SASL support in HTTP?
Thread-Index: AQHSZO1RSepZQ0ifxE6hB+xKODPLpaEnq+uA//+12YA=
Date: Tue, 03 Jan 2017 23:05:02 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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-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

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" < on behalf of> wrote:

    Already tried once:
    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-auth mailing list
    Kenneth Murchison
    Principal Systems Software Engineer
    Carnegie Mellon University
    http-auth mailing list