Subject: Re: [http-auth] [kitten] [saag] HTTP authentication: the next generation

From: Josh Howlett <[email-masked]>
Date: Sun, 12 Dec 2010 09:16:58 +0000

Right, HTTP authentication is out of Abfab's scope. My point was that Abfab is doing stuff that may nonetheless be useful for some other effort looking at the problem.

I agree with your observation re federation, but note that EAP authentication does not imply federation.

Josh.

--- original message ---
From: "Yoav Nir" <[email-masked]>
Subject: RE: [kitten] [saag] HTTP authentication: the next generation
Date: 12th December 2010
Time: 8:42:08 am

To quote from Abfab's charter:

                 This working group will specify a federated identity
  mechanism for use by other Internet protocols not based on HTML/HTTP,

For just adding authentication to HTTP, I don't think it makes sense to add federation. All kinds of services such as web mail, online gaming, and online shopping require authentication, but there's no federation involved.

-----Original Message-----
From: Josh Howlett [mailto:[email-masked]]
Sent: 12 December 2010 10:30
To: Yaron Sheffer; Luke Howard
Cc: [email-masked]; [email-masked]; Yoav Nir; websec; Paul Hoffman; [email-masked]; [email-masked]; [email-masked]; Hannes Tschofenig; Josh Howlett; [email-masked] Group
Subject: Re: [kitten] [saag] HTTP authentication: the next generation

AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods you mention. This mechanism could be run over SASL-TLS using GS2.

Josh.

--- original message ---
From: "Yaron Sheffer" <[email-masked]>
Subject: Re: [kitten] [saag] HTTP authentication: the next generation
Date: 12th December 2010
Time: 7:36:41 am

Hi Luke,

I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent.

There is a number of EAP methods that provide zero-knowledge password based mutual authentication (i.e. password based auth that's *not* susceptible to dictionary attacks). These include (see
http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3):
EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE.

As far as I can see
(http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml),
SASL does not provide any equivalent method.

Thanks,
        Yaron

On 12/12/2010 03:38 AM, Luke Howard wrote:
>
> On 12/12/2010, at 10:10 AM, Yoav Nir wrote:
>
>>
>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote:
>>
>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote:
>>>> Other than that, I'm not aware of much activity. What have I missed?
>>>
>>> TLS client certificates.
>>
>> TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication.
>>
>> http://tools.ietf.org/html/draft-nir-tls-eap
>
> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equivalent?
>
> -- Luke
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Scanned by Check Point Total Security Gateway.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 Dec 2010 06:11:11 -0500

--On Friday, December 17, 2010 6:18 PM +1300 Peter Gutmann
<[email-masked]> wrote:

> John C Klensin <[email-masked]> writes:
> 
>> We could round up a collection of UI experts to look at some
>> of these things  and have them shake their heads and say
>> "royal mess you have gotten yourselves  into".
> 
> The problem isn't that UI experts haven't looked at this,
> there have been a  large number of papers published on this
> problem over the last decade or so,  it's that it's proven
> pretty much impossible to get any action taken over it.  The
> browser approach is "PKI isn't working, so we'll respond with
> even more  PKI (EV certs) while stridently ignoring any
> workable alternatives (TLS-SRP  and -PSK)", and there's no
> sign that this will ever change.  There simply isn't a hammer
> big enough to force a change here (or, if there is, no-one's
> managed  to identify it yet).

I perhaps should have said "...yet another collection of UI
experts..." and "shake their heads again...".

But I don't think we disagree: from my point of view, you are
just describing some aspects of what I tried to summarize as
"royal mess".   I do think there is at least one big enough
hammer although I'm not predicting we will get there soon and
really don't like seeing protocols designed by a sequence of
disaster, legal action, and legislation.  And, I am not, for the
record, offering an opinion as to whether the approaches you
suggest are workable and/or the right answers.

   john