IETF Logo Mail Archive

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

Ken Murchison <murch@andrew.cmu.edu> Tue, 03 January 2017 22:30 UTC

Return-Path: <murch@andrew.cmu.edu>
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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietfa.amsl.com>; 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 <http-auth@ietf.org>; 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 <http-auth@ietf.org>; Tue, 3 Jan 2017 17:30:26 -0500
To: http-auth@ietf.org
References: <586A3C94.4090504@openfortress.nl>
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
Message-ID: <8fe83a05-d104-4fee-f483-0ff74e84b80e@andrew.cmu.edu>
Date: Tue, 03 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: <https://mailarchive.ietf.org/arch/msg/http-auth/48sPonnYt6eRROKtNev-jHIAYOE>
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 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

v2.23.0 | Report a Bug | By Email