IETF Logo Mail Archive

Re: [kitten] GSS-API and timeouts

Simon Josefsson <simon@josefsson.org> Wed, 04 April 2012 17:46 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6783E21F87D3 for <kitten@ietfa.amsl.com>; Wed, 4 Apr 2012 10:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.789
X-Spam-Level:
X-Spam-Status: No, score=-99.789 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+zLe1ZyUmSX for <kitten@ietfa.amsl.com>; Wed, 4 Apr 2012 10:46:55 -0700 (PDT)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADC821F8772 for <kitten@ietf.org>; Wed, 4 Apr 2012 10:46:54 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q34HkfRS004188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2012 19:46:43 +0200
From: Simon Josefsson <simon@josefsson.org>
To: William Mills <wmills@yahoo-inc.com>
References: <87obr7lfqc.fsf@latte.josefsson.org> <1333554083.71760.YahooMailNeo__8959.87156914107$1333554099$gmane$org@web31804.mail.mud.yahoo.com> <87limbju45.fsf@latte.josefsson.org> <1333560942.30565.YahooMailNeo__42659.7644495361$1333560961$gmane$org@web31804.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:120404:kitten@ietf.org::BQ93Gk1pbWQsnTzg:cuit
X-Hashcash: 1:22:120404:wmills@yahoo-inc.com::Mbsyl0mKL3aTLcpm:043RK
Date: Wed, 04 Apr 2012 19:46:36 +0200
In-Reply-To: <1333560942.30565.YahooMailNeo__42659.7644495361$1333560961$gmane$org@web31804.mail.mud.yahoo.com> (William Mills's message of "Wed, 4 Apr 2012 10:35:42 -0700 (PDT)")
Message-ID: <87wr5vie4j.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] GSS-API and timeouts
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 17:46:56 -0000

William Mills <wmills@yahoo-inc.com> writes:

>>> As a result of the OpenID flow/redirect don't you get a complete
>>> credential that can be used to finish the process?  Can't you connect
>>> again, get a challenge perhaps, submit that completed credential and
>>> be done?  That's very similar to what I did in the OAUTH/SASL thing,
>>> so I'm replaying my one trick :)
>>
>>The problem is that the browser interaction in OPENID20/SAML20 can take
>>a long time because it is interactive, and the server doesn't know when
>>to stop waiting.
>>
>>/Simon
>>
>
> Yes, but if you can support an async style thing then you can just fail
> the first auth, hold the connection open, and let the client do a second 
> auth.  Server then limits the total number of allowed failed auth
> transactions.

I don't see how that works for OPENID20/SAML20 -- because the client
doesn't get any token that could be used for the next SASL session.  The
server still has to wait for the first authentication to complete
eventually (of course the client can close that connection to indicate
cancelation but that is rather brutal).

/Simon

v2.23.0 | Report a Bug | By Email