Subject: HTTP authentication: the next generation

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Dec 2010 15:53:53 -0700

Is it time to start thinking about next-generation authentication
technologies for HTTP?

We all know that BASIC and DIGEST are ancient and crufty and lacking
many features and security properties we might want, but there hasn't
been much discussion about more modern approaches. Here are a few things
I've found:

1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL
within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt

2. In 2007, Robert Sayre put together a few slides on the topic:
http://people.mozilla.com/~sayrer/2007/auth.html

3. Yutaka Oiwa and his colleagues have been working on a protocol for
mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08

Other than that, I'm not aware of much activity. What have I missed?
Does it make sense to perhaps hold an exploratory BoF at the next IETF
meeting (Prague, March 2011) to get people thinking about this topic?

If you're interested, please discuss on the [email-masked] list:

https://www.ietf.org/mailman/listinfo/http-auth

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 11 Dec 2010 10:06:00 +1100

There was a very well-attended and wide-ranging bar BoF in Vancouver, and lots of background discussion (/noise).

My impression at that point was that the use cases that people wanted to put into scope were so diverse, and the requirements so exacting, that it was a non-starter. 

That may still be the case, and I think that without a concrete target, starting the discussion again will ultimately just waste a lot of engineer hours*.

Having said that -- since we now have OAuth shaving off some of those use cases, it may be that a purely browsing-focused authentication mechanism might be able to get traction, provided we can get browser vendors on board (naturally). I'd expect them to instigate this, however.

Cheers,

* Waste, of course, is subjective. A cynical person would think that the opportunity cost of having a bunch of standards people working on something non-productive could, in the end, be a useful diversion. However, I'm not that person, because I'm not thinking it, I'm saying it. But I digress.

On 11/12/2010, at 9:53 AM, Peter Saint-Andre wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Dec 2010 15:09:39 -0800

>Other than that, I'm not aware of much activity. What have I missed?

TLS client certificates.

--Paul Hoffman, Director
--VPN Consortium

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Dec 2010 17:10:30 +0300

Yaron Sheffer wrote:

> 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.

There is an expired SASL SRP draft, which can be revived, if needed.

> 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:
>>>
>>> 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
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Dec 2010 21:40:49 +0300

Yoav Nir wrote:

>EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETER infrastructure.
>
True.
And SASL has an advantage that it is easier to integrate with LDAP 
infrastructure.

I think this just demonstrates that before an HTTP authentication 
mechanism can be evaluated, people need to agree on a common evaluation 
criteria for HTTP authentication.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 12 Dec 2010 14:39:23 -0800

On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote:

> And SASL has an advantage that it is easier to integrate with LDAP infrastructure.
> 
> I think this just demonstrates that before an HTTP authentication mechanism can be evaluated, people need to agree on a common evaluation criteria for HTTP authentication.

Define them all and let's have a bake-off.  It has been 16 years since
HTTP auth was taken out of our hands so that the security experts could
define something perfect.  Zero progress so far.  We should just define
everything and let the security experts do what they do best -- find the
holes and tell us what not to implement.

....Roy

---

From: Dave Raggett <[email-masked]>
Date: Mon, 13 Dec 2010 10:17:34 +0000

And let's not ignore secure privacy enhancing technologies like
anonymous credentials and zero knowledge proofs, see e.g:

http://www.w3.org/QA/2010/11/boosting_privacy_online_-_anon.html

It is often sufficient to know that someone is a member of a group or
has certain attributes rather than knowing exactly who that person is. 

Perhaps we could add to SASL the notion of secure anonymous access for
authenticated access?  This involves the client generating and passing a
proof to the server that satisfies the proof specification and nonce
provided by the server.

[ Jan, see http://datatracker.ietf.org/wg/kitten/charter/ ]

n.b. this work was carried out with support from the European PrimeLife
project on privacy and identity, see http://www.primelife.eu/

On Sun, 2010-12-12 at 14:39 -0800, Roy T. Fielding wrote:
> mechanism can be evaluated, people need to agree on a common
> evaluation criteria for HTTP authentication.
> 

-- 
 Dave Raggett <[email-masked]> http://www.w3.org/People/Raggett

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Dec 2010 10:25:52 +0000

On Sun Dec 12 22:06:29 2010, Yoav Nir wrote:
> - It has to be integrated in the protocol, not the application

What?! No. It must be integrated in the application. If nothing else  
can be learnt, then learn this one thing - we have had Basic and  
Digest support in the protocol for years, but because they cannot  
easily be integrated into the application, no serious consumer  
applications use them, even though what they provide is never any  
better than Basic.

If I could wave a magic wand and have all my wishes come true, I'd  
embed SASL into the web browser such that:

- Users are presented with visually-distinct controls embedded into a  
web page for authentication, much like Extended Validation. Perhaps  
focussing them turns the address bar red or something.
- The SASL message exchanges happen over a WebSocket or equivalent  
low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I  
imagine a webbrowser gets given one or more URIs to use for  
communications).
- The result of this is a one-time password intializer.
- Subsequent requests and responses occur with traditional HTTP auth,  
using some OTP mechanism that requires only a single message.

The two parts of the protocol can, and should, be split - many  
existing websites use a cookie as the result of authentication, and  
having a more secure variant of this alone would be extremely useful.

Note that the key portion of this - embedded SASL - is not really  
HTTP auth at all, but a Web Application Auth - since that's really  
the other party to the authentication, it seems quite obvious to me  
that this should be the authenticating entity.

> - It has to be secure against phishing - if the attacker gets you  
> to authenticate, they can't later use that authentication to  
> connect to the real server
> - If the authentication succeeded, then (a) you typed your password  
> correctly, and (b) this is really the server
> 
> EAP has some methods that do this. SASL can probably be made to do  
> this, but with an extra layer.
> 
> 
SASL also has methods that will do this, I think - I'm not sure what  
additional layer you're referring to here.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 13 Dec 2010 23:55:11 +1300

you might want to reconsider.

for instance what would you propose for non-browsers, which perform a 
large proportion of all HTTP transactions.

Also, it seems like it would make the problem about a billion times 
worse putting the auth into the application, where there are no 
standards, and therefore it would need to be re-implemented for each 
different application... kinda like what we have now already.

SASL is an orthogonal concept.  It's just a framework to negotiate auth, 
whether that's over HTTP or something else.  So, it's a bit of a red 
herring in this.

Yoav is correct, the auth must be in the protocol (1 of these) as 
opposed to the application (too many of these).

The trick is to get the application to actually use the auth of the 
protocol.

Adrien

On 13/12/2010 11:25 p.m., Dave Cridland wrote:
> Note that the key portion of this - embedded SASL - is not really HTTP 
> auth at all, but a Web Application Auth - since that's really the 
> other party to the authentication, it seems quite obvious to me that 
> this should be the authenticating entity.
>
>
>> - It has to be secure against phishing - if the attacker gets you to 
>> authenticate, they can't later use that authentication to connect to 
>> the real server

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Dec 2010 11:23:04 +0000

On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote:
> for instance what would you propose for non-browsers, which perform  
> a large proportion of all HTTP transactions.
> 
> 
I agree a solution is needed for non-browsers (including IPP, for  
example). I disagree this needs to be, or should be, the same as a  
solution for web apps. I disagree that non-browser security is even a  
major priority at this point in time - it's adequately served by TLS  
and client certificates and/or Basic auth, depending on the security  
model desired - this latter I appreciate is a personal opinion.

However there is no doubt at all that current webapp deployments are  
in need of a serious improvement in security, given that these  
generally use TLS only during authentication itself, and use  
plaintext usernames and passwords for the authentication itself.

> standards, and therefore it would need to be re-implemented for  
> each different application... kinda like what we have now already.

Yet every webapp currently uses a form, and it's so close a standard  
that browsers can, and do, spot login forms and allow the credentials  
to be cached. As such, I fail to see why we wouldn't want to place  
better authentication at that layer, where it's quite likely to be  
actually used.

> SASL is an orthogonal concept.  It's just a framework to negotiate  
> auth, whether that's over HTTP or something else.  So, it's a bit  
> of a red herring in this.

Right, that's fair enough.

> The trick is to get the application to actually use the auth of the  

Yes, but the problem is that existing, deployed, webapps could use  
Basic right now - they all just ask for a username and password after  
all. Yet none of them do, in part because of integration issues, but  
mostly I suspect due to usability and branding issues.

We could deploy some more advanced mechanisms in HTTP auth tomorrow,  
and nobody would use those either.

Dave.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Dec 2010 12:08:43 +0000

On 11 December 2010 23:10, Yoav Nir <[email-masked]> wrote:
> 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.

I think what we've learnt is that we need to provide good UI and
portability if we want people to use them.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Dec 2010 13:14:03 +0100

On Dec 13, 2010, at 12:23, Dave Cridland wrote:

> every webapp currently uses a form

Yes.  Nice demonstration of conflicting requirements.

As a webapp developer, I want to control the user interface during authentication.
Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide.
I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method.
HTML/CSS/JS lends itself well to providing such a friendly user interface.

As a security geek, I recognize this as exactly the problem that creates the potential for phishing.
Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding.

Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions.
Replacing <input type="password"/> for the 21st century.  This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope.  "Storing passwords" in the browser might turn into storing those security associations.

This is not "HTTP authentication", but it might be more useful in the long run.
We'll need the browser people to start any such effort.

Gruesse, Carsten

PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope.  But that is a completely different animal.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Dec 2010 15:16:12 +0000

On Mon Dec 13 12:14:03 2010, Carsten Bormann wrote:
> Maybe the only way to address both requirements is to have  
> something in HTML/CSS/JS that addresses authentication interactions.
> Replacing <input type="password"/> for the 21st century.  This  
> would allow web app designers to design a nice context for this  
> interaction, and would allow running security protocols that are  
> binding themselves to a browser-server security association that  
> may be identical to or different from the TLS envelope.  "Storing  
> passwords" in the browser might turn into storing those security  
> associations.
> 
> 
Or storing credentials rather than username/password pairs, possibly.

But in any case, I think that's close to what we want. As I say, I  
think we need to establish a session credential of some kind that can  
be used over unencrypted sessions with some improvement in security  
over typical fixed cookies that exist today. I'm fine if one of these  
credential options happens to tie into a TLS property, but I think  
we'll have to have reasonable security over non-TLS, too. (And by  
"reasonable", I'm expecting this to be "not as good as if you had  
TLS")

And I absolutely agree that this effort needs strong support from the  
browser implementors from the start - we also need the same from a  
few major webapps.

Dave.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2010 16:39:22 +0100

On 10.12.2010 23:53, Peter Saint-Andre wrote:
> ...

Probably. But while doing so, we need to look at the existing base as well.

HTTPbis now includes the HTTP authentication framework (essentially 
RFC2617 minus Basic and Digest). The HTTPbis WG is interested on 
feedback on the remaining issues (such as Realm required?, and 
considerations for new schemes).

Also, I believe Basic is not going to go away, and I'd really like to 
fix its I18N problem. Proposal here: 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-01.html>.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Dec 2010 16:27:55 +0000

On 13/12/10 15:29, Yoav Nir wrote:

>     * A possible solution to the first problem would be to issue
>       multiple certificates for use in phone, laptop and desktop. But
>       this makes the management of all these certificates even more
>       complicated, and increases the attack surface.

Just a random thought. What if there were a standard way for web server
apps to bind together different client public keys? E.g. start at home,
with TLS mutual auth somehow, then go to the standard "bind new device"
button which returns a shortish URL that the user can cut'n'paste to
a 2nd device, also using TLS mutual auth, but with the key pair from
that 2nd device. Then the server could associate a set of client public
keys with the same account. (The URL could probably also be made only
usable on that server as well via some server-side symmetric crypto
maybe.)

Probably has holes galore, (and/or was tried a decade ago;-) but at
least the browsers could work as-is. Well, as-is if you assume people
had a way to generate and manage key pairs easily in their various
browsers.

Regardless of the above, I think that if there were a usable way to
do TLS mutual auth that was unencumbered and worked well, (including
tackling portability), that'd be great, and even if the probability
of failing is high, trying for that is maybe worth a shot.

S.

---

From: Tim Morgan <[email-masked]>
Date: Mon, 13 Dec 2010 09:10:33 -0800

Hi Everyone,

These last few messages do a great job outlining both the real
problems that face adoption of HTTP authentication without a
customizable user interface, and the fact that HTTP authentication is
perhaps more secure than form-based authentication (as well as being a
requirement for automated/non-GUI clients).

I did some work not long ago on this and found that we can have our
cake and eat it too.  That is, even with current browser
implementations, one can utilize HTTP Basic/Digest with an HTML form
(if desired).  (Yes, once again, HTML forms may allow for easier
phishing, etc, but that is what the HTTP Mutual authentication
proposal can address.)

My position paper is here:
  http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

And some proof of concept code for forms-based HTTP authentication can
be found on this page:
  http://vsecurity.com/resources/tool

The implementation is hacky right now, because, at the time of
development and testing, browsers didn't adhere well to the draft
XMLHttpRequest standard.  I haven't checked the status of browser
implementations, but the proposed standard still requires a behavior
that is workable with such a system.

So all of these pieces are coming together on their own to allow for
forms-based HTTP authentication.  The major outstanding piece needed
for most web applications with HTTP authentication is the ability to
log out.  The ability to instruct a browser, in an standard way
(preferrably with HTTP response headers) to forget the credentials it
has cached.  Writing a draft RFC for this has been on my list for some
time, but I've been quite busy this year.  For those interested, I can
dig up some of the previous discussion threads...

cheers,
tim

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 13 Dec 2010 13:57:03 -0500

On Dec 13, 2010, at 10:32 53AM, Yaron Sheffer wrote:

> Just like the phrase "I am not a lawyer" is always followed by amateur legal advice (I know that for sure, I've done it myself), the same goes for "I am not a UI expert".
> 
> Two comments:
> 
> - There are in fact a few security-usability experts. I don't know if any of them participate in the IETF. This is an emerging research field, see e.g. http://oreilly.com/catalog/9780596008277.
> 
> - (I am not a UI expert, but...) Devising UI cues is extremely difficult. People will gladly enter their password when the web site displays a JPEG-rendered padlock icon. In fact *legitimate* sites have been known to display such icons, strange as it may sound.

Security and usability *is* one of my research areas.  I agree with Yoav: there are many problems with use of client-side certificates.  In general, I like them -- the only way to log in to the computers I control is with public-key authenticated SSH -- but there are very good reasons why they are seldom used.  Private key storage and transport is the major one, but key issuance and recovery from lost or stolen keys are serious issues as well.  The security community has made that worse by layering heavyweight policies and procedures on top of the certificate issuance process, even when the value of the resource being protected isn't high enough to justify it.

(I've been worrying about usability issues for a long time.  There was one I-D that I dealt with as AD that I abstained on -- I wouldn't vote "no-ob" because I did object, but I had no better suggestion than "go back and start over".  While dealing with that document, I emailed one of the top usability people and asked

	Do you know of papers on the difficulty of administering complex 
	access control lists?  I'm trying to convince people that a 
	seriously-complex scheme will lead to massive security failures, 
	because no one will be able to get the ACLs right.

So yes, there are people in the IETF who worry about UI issues.)

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Dec 2010 15:18:33 -0500

Actually, sounds like it might be a handy usage of OAuth.  The whole point of that protocol is to delegate user authorizations.  This is just the case where the user is delegating his entire set of authorizations to another instance of himself.
--Richard

On Dec 13, 2010, at 11:27 AM, Stephen Farrell wrote:

> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 14 Dec 2010 15:25:48 +0900

Dear Yoav,

[notice: Reply-to limited]

(1) I largely agree with your view on Cookie and Client certificates.
Client certificates are only useful for Web world in very limited cases.
In reality, many banks in Japan (may be in US too?) introduce cert
authentication for corporate-account on-line banking but not for personal
account counterparts.  It introduce heavy burden for both server and client
sides, which cannot be justified for required security.

Also, use cases of Web authentication is not limited to the "strong identity"
which usually tied with the client certificates and CA hierarchies.
In many use-cases sites introduce simple interfaces accepting "almost anonymous"
registrations.  Issuing a certificate for every user of every such services is
unlikely, and tieing those accounts with existing client certificates introduces
serious privacy concerns.

(2) However, I am not agreeing with putting the authentication in the
layer lower than HTTP.  TLS authentication will only work for site-wide fixed
setting of authentications, which is not deployable for large numbers of
websites.  See how Yahoo serves for both unauthenticated and authenticated
users, and how Google implements their "GMail for your domains" (log in/out
control is independent for each domain-account, hosted on the single server).

More technically,  It is semantically wrong.  HTTP has two layers of "messaging
channels" inside it: the lower level is a "keep-alive" stream transport (TCP and
TLS), and the higher level is a packet interface made by pairs of a request and
a response.  From the application point of view, the authorization happens on
the higher level.  For each resources the server may either request or not
request the authentication, and the clients respond with that.  The resources on
a single server may belong to several separate "authentication realms",
including special "unauthenticated" one.  For such settings, authentication
should be tied to the "higher level" in whatever way.  If you put authentication
in the lower level, requests for the different realms wil mix up in the
inappropriate lower channel.  Changing those semantics is too hard and seems
inappropriate for any deployments.

This gives an answer for the reason that *for some Web/HTTP application* TLS
auth works: each of these is so simple enough that it only have a one
"authentication realm" inside it.  The corporate banking is so, and so is IPP.
It is also true for many non-HTTP TLS applications such as POP3 and IMAP.
But it is not true for general Web applications, end we cannot enforce such
design restrictions for Web services.

People often concern about the security impact which arise from putting auth in
the higher layer.  Such a problem can be solved technically, for example by
using channel bindings.  Careful designs of protocols can gives even better
operational properties than TLS-based authentications.  For example, our Mutual
auth proposal can be used securely on HTTPS, preventing man-in-the-middle
credential forwarding attacks, while allowing off-loading of TLS overhead to
existing hardware TLS accelerators without any changes.

(4) For non-TLS applications:  in the real world I've heard too much voices
about inapplicabilities of HTTPS in the real systems.  I think that
authentication in the non-HTTPS world MUST be improved, too.  In fact, not a
single person asked (requested) me whether our Mutual authentication can be used
for integrity protection on non-HTTPS responces, as HTTPS is not deployable for
whole their services, and they need to improve authentication (and integrity).

On 2010/12/13 17:49, Yoav Nir wrote:
> 
> On Dec 13, 2010, at 2:49 AM, Marsh Ray wrote:
> 
>> On 12/12/2010 04:39 PM, Roy T. Fielding wrote:
>>>
>>> Define them all and let's have a bake-off.  It has been 16 years
>>> since HTTP auth was taken out of our hands so that the security
>>> experts could define something perfect.  Zero progress so far.
>>
>> Perhaps it's a bad idea?
> 
> Disagree. Authentication is very much needed in the web. The current state is that websites have you fill in a form, and store a session cookie. We all know how this fails. An attacker can make a login page that looks like google's or paypal's or bankleumi.co.il just as easily as the respective organizations, and gain access to their credentials.
> 
> This is good enough for Google, who need the cookies to track your searches and emails so as to match them to ads. A little bit of someone searching the web with someone else's userid doesn't make much difference to them. But if I have some important information in my gmail account, or money in bankleumi, I would like to avoid sending my password in the clear to an attacker's site.  And things like SRP can do this. If SRP succeeds with a remote server, I know that it's the right server.
> 
> Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used.
> 
> I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords.
> 
>>
>>> We
>>> should just define everything and let the security experts do what
>>> they do best -- find the holes and tell us what not to implement.
>>
>> I know some professional pen-testers who would love that!
>>
>> Check out these videos. This is what happens when you take a 
>> general-purpose authentication protocol and repurpose it for use across 
>> the internet for an insecure application protocol:
>>
>> http://extendedsubset.com/smb_relay_fully_patched.wmv
>> http://extendedsubset.com/smb_reflection_arp_poisoning.wmv
>> http://extendedsubset.com/?p=36
>>
>> This case is NTLMv2, but the phenomenon is not limited to that.
>>
>> The problem is that most general-purpose authentication protocols do not 
>> require enough specificity about the context of the authentication: who 
>> and what are you authenticating, to whom, and how does each side know 
>> it's operating under the same beliefs as the other?
>>
>> This means that even if the client wants to be careful and authenticate 
>> only for the purpose of setting up a secure connection, the attacker can 
>> possibly forward that authentication to auth his own connection or 
>> transaction on some other service (on the same or even a different server).
>>
>> Most auth protocols don't let the client strongly verify the server's 
>> identity before the client has to authenticate with his own. This is 
>> probably at least in part because it requires some common infrastructure 
>> to do this. So Kerberos and x509 PKI systems can authenticate the server 
>> (and sometimes even the target service), but most others do not.
>>
>> Since HTTP lacks connection integrity, it's meaningless to speak of "an 
>> authenticated client". Perhaps the only thing that could be meaningfully 
>> authenticated is the request data itself. But auth protocols designed 
>> for setting up persistent connections typically don't have defined 
>> inputs for the message data/digest being signed, so it's often 
>> impractical to reuse them for that purpose.
>>
>> These issues have been mostly addressed at the protocol level for TLS 
>> client cert authentication. If it really just comes down to deployment 
>> and client usability issues, it's hard to imagine coming up with 
>> something at another layer which would have less risk than building on 
>> top of that.
>>
>> Deploying new uses of compatible, standard authentication protocols over 
>> insecure application protocols can be bad for the greater security 
>> ecosystem because it widens the field for cross-protocol attacks.
>>
>> - Marsh
>> websec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/websec
>>
>> Scanned by Check Point Total Security Gateway.
> 
> http-auth mailing list
> [email-masked]
-- 
大岩 寛   Yutaka Oiwa                       独立行政法人 産業技術総合研究所
            情報セキュリティ研究センター ソフトウェアセキュリティ研究チーム
                                      <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Tim Morgan <[email-masked]>
Date: Tue, 14 Dec 2010 17:13:28 +0000

Hi Marsh,

> IMHO, authentication just doesn't belong at the HTTP layer.

Hmm, can't necessarily disagree there...  However, I think having it
in the next layer up (POST requests/cookies) is even worse.

> HTTP is inherently bad at being stateful. Stateless interfaces can
> be fantastic, but it doesn't support the "login session" concept
> that most people have in mind when they talk about authentication.

HTTP isn't good at being stateful, but it is.  One could argue that
even just Basic auth alone adds state.  Cookies add state, and we have
connection state.

Ultimately, a non-security form of state management buys a security
protocol nothing.  I think time and again we have found that relying
on insecure underlying state mechanisms in a secure protocol will
bring about insecurities.  Secure protocols need their own state
management independent of the underlying layers.

> Unless you're properly using TLS, you have no reason to believe that
> the byte you just received is from the same party as the previous
> byte you received. So under those circumstances, what exactly are
> you authenticating, and to whom?

Agreed.

> I use a lot of web sites and none of them do authentication via
> HTTP. Every single one of them expects a username/password via
> HTTP(s) POST variables and returns a cookie of varying duration.

Right, and this needs to change, IMHO.  While I'd love to see lots
more adoption of TLS client certificates, I don't think it will ever
completely supplant username/password pairs.  This is because most
people don't understand certificates while everyone understands
usernames and passwords.  Also, there are some real differences in use
cases which will create problems for some sites.

> But what could we possibly do for a stateless, unMACed protocol like
> HTTP, except integrate and bind it better with a lower layer
> providing real integrity?

That's pretty much the solution that Yutaka OIWA and the other Mutual
auth folks have come up with.  You have a protocol over HTTP which
mutually guarantees the server and client have the same password
without leaking the password (this prevents phishing even if users
don't look at the domain name) and this cryptographic process is tied
to the TLS server certificate to prevent MitM.

Could the same security properties be achieved with TLS and say, SRP?
Probably.  The hurdle that SRP has is the user interface. Users and
web developers are accustomed to being able to build their own login
forms.  Now that we (the security community) let them get away with
this foolishness, we can't really take it away from them again. Very
few web developers will give up the ability to build a branded, custom
login form just to use something more secure like SRP over TLS.  So,
how would you go about making it usable with HTML login forms?  I'm
not sure. 

What I *have* investigated in the past is the ability to do HTTP
authentication with custom HTML login forms.  I've found it's not only
possible right now, but the tools to do it (XMLHttpRequest, mostly)
are becoming standardized in a way that makes it well-defined.  So,
there we could have a reasonable tradeoff between usability and
improved security if we pushed for HTML login forms with Mutual auth.

> I think what the world needs are ways for web apps (literally, the
> Ruby code) to easily work with the strongly-authenticated identities
> which are supported at the TLS layer. TLS already supports
> "sessions" and "client authentication", but for whatever reasons
> they're not being utilized. We should make using those facilities as
> easy for web developers as doing cookie-based logins.

Yes, exactly.  So we've already covered how there are many protocols
and protocol frameworks which are secure and integrate well with this,
that, or the other backend system.  Why aren't these adopted already?
It all comes down to how easy it is for web developers to present a
"user friendly" login process.  I think we have enough good crypto out
there.  We should focus on how to make that crypto easier to deploy.

Regards,
tim

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Dec 2010 14:23:45 -0500

--On Monday, December 13, 2010 13:57 -0500 Steven Bellovin
<[email-masked]> wrote:

>... 
>> Just like the phrase "I am not a lawyer" is always followed
>> by amateur legal advice (I know that for sure, I've done it
>> myself), the same goes for "I am not a UI expert".
>> 
>> Two comments:
>> 
>> - There are in fact a few security-usability experts. I don't
>> know if any of them participate in the IETF. This is an
>> emerging research field, see e.g.
>> http://oreilly.com/catalog/9780596008277.
>> 
>> - (I am not a UI expert, but...) Devising UI cues is
>> extremely difficult. People will gladly enter their password
>> when the web site displays a JPEG-rendered padlock icon. In
>> fact *legitimate* sites have been known to display such
>> icons, strange as it may sound.
> 
> Security and usability *is* one of my research areas.  I agree
> with Yoav: there are many problems with use of client-side
> certificates.  In general, I like them -- the only way to log
> in to the computers I control is with public-key authenticated
> SSH -- but there are very good reasons why they are seldom
> used.  Private key storage and transport is the major one, but
> key issuance and recovery from lost or stolen keys are serious
> issues as well.  The security community has made that worse by
> layering heavyweight policies and procedures on top of the
> certificate issuance process, even when the value of the
> resource being protected isn't high enough to justify it.
> 
> (I've been worrying about usability issues for a long time.
> There was one I-D that I dealt with as AD that I abstained on
> -- I wouldn't vote "no-ob" because I did object, but I had no
> better suggestion than "go back and start over".  While
> dealing with that document, I emailed one of the top usability
> people and asked
> 
> 	Do you know of papers on the difficulty of administering
> complex  	access control lists?  I'm trying to convince people
> that a  	seriously-complex scheme will lead to massive
> security failures,  	because no one will be able to get the
> ACLs right.
> 

Steve,

I worry too.  And, while I effectively dropped out of the field
--in terms of making any useful contributions-- about 25 years
ago, I do try to track the literature (without great success).
Observations:

(1) The folks who taught me about what was then called "human
factors in computing" in the 70s suggested that one key issue
was to design from error/failure states backwards to both
detailed system design and UI.  If one could not do an analysis
of failure states, then one wasn't ready to design the
interfaces of the system.  If the right information is not
available in the right place to produce a coherent message and
make it actionable, patching things on just don't work.  From
that perspective, it is as hard or harder to graft a good UI
onto a system that wasn't designed with UIs in mind as it is to
graft good security onto a system that wasn't designed for that.
A large number of modern systems --and IETF protocols-- fail on
both dimensions.

(2) Even without any research, it should be obvious to us all
that presenting a user with a dialog box with a string of text
that might be informative to an expert but is pure gibberish to
the user, followed by some choice, is not going to produce good
results.  The question of whether the choice in that situation
should be a pair of boxes labeled "yes" or "no" (or equivalent)
or a single box labeled "ok" (or equivalent) is, IMO, of purely
academic concern.  Unless the user can make an informed
decision, decision/dialog boxes or other types of questions
aren't about UIs but about attempted sops for the conscience of
the implementer.  Almost everything I've seen that attempts to
deal with certificate validation failures falls into that
general category.  Things would be considerable better if we
never had a false negative (bad certs could just be rejected,
action dependent on them stopped, and the user informed, not
asked), but that seems unlikely at least as long as we have
relatively simple cases like administrative failures to install
new certs before old ones expire.

(3) I think the above suggests that your "seriously complex
scheme" criterion is much too high a bar.  Even a moderately
complex scheme that depends on lots of factors or subtle
interactions will fail.  If the ACLs don't get people, then user
inability to deal with explanations of the failures will.

(4) The problem with your comments, and even more so the problem
with mine above, is that they are not usefully actionable in the
IETF.  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".  That, like your
comments and I hope mine, would be true... and equally useless
vis-a-vis digging ourselves out.  

I hope this isn't as hopeless as it feels to me sometimes,
but... do you have suggestions?

     john

---

From: der Mouse <[email-masked]>
Date: Thu, 16 Dec 2010 18:28:14 +0000

>> * Certificates do not authenticate the user.  They authenticate a
>> device.
> I don't think they do that exactly either.  The client cert is
> generally public, its private key is a secret like a password, but
> one that's too hard to memorize.

Quite aside from memorizability, few-to-no humans are capable of
performing the cryptographic operations (large-number arithmetic,
usually) necessary to carry out certificate operations, at least not
with the required levels of reliability.  (I can do multi-hundred-digit
arithmetic, yes, but not nearly either fast enough or free enough of
mistakes to be useful for the purpose.)

Certificates, at best, determine that some device which is capable of
performing the cryptographic operations has been given access to the
corresponding private data.  This is close enough to authenticating a
user to be useful for many purposes, but it is not the same thing.

Of course, the same is true of passwords.  All passwords demonstrate is
that some device capable of injecting data into the comm channel in
question knows the password.  But passwords rarely lull people into
forgetting the difference.

> For most systems, the vast majority of 'no's are not actual attacks.

Are you sure of that?  There are an awful lot of doorknob-rattlers out
there.  Most of the login failures I see on my machines actually _are_
attackers poking to see if I've made stupid mistakes.

> Yeah.  How did the user select their password for the website in the
> first place, if not by an HTML form POST?

> If it was good enough for the initial sign up, why should the web
> designer use something other than HTML form POST for the regular
> login?

For all that that's rhetorical, there is an answer: because one occurs
only once while the other occurs many times.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 18 Dec 2010 16:48:42 +0000

I think that we need to distinguish between an authentication mechanism and
an authentication infrastructure.

Part of the problem with HTTP authentication is that it was
quickly superseded by HTML based authentication mechanisms. And these in
turn suffer from the problem that password authentication fails when people
share their passwords across sites, which of course they have no choice but
to do when every stupid web site requires them to create yet another stupid
account.

Since Digest Authentication became an RFC, I don't think there has ever been
more than about 6 weeks elapsed without someone suggesting to me that we
include SHA1 or SHA2 as a digest algorithm. Which is of course pointless
when the major flaw in the authentication infrastructure is the lack of an
authentication infrastructure. The original reason for designing Digest the
way that I did was that public key cryptography was encumbered. Had public
key cryptography been available, I would have used it.

By authentication infrastructure, I mean an infrastructure that allows the
user to employ the same credentials at multiple sites with minimal or no
user interaction. I do not mean a framework that allows for the use of 20
different protocols for verifying a username and password.

We do have almost as many proposals for federated authentication as
authentication schemes of course. But each time there seems to be an
obsession with things that technocrats obsess about and at best contempt for
the actual user.

OpenID almost succeeded. But why on earth did we have to adopt URIs as the
means of representing a user account? And why was it necessary to design a
spec around the notion that what mattered most in the design of the spec was
the ability to hack together an account manager using obsolete versions of
common scripting languages?

Another feature of that debate I cannot understand is why we had to start
talking about 'identity' as if it was some new and somehow profound problem
that had only just been discovered.

There is of course a standard for representing federated user accounts that
has already emerged on the net. And once that is realized, the technical
requirements of a solution become rather obvious.

As Web sites discover that their account holders cannot remember their
username, most have adopted email addresses as account identifiers. That is
what we should use as the basis for federated web authentication.

So if the user account identifier looks like [email-masked], how does
an entity verify that a purported user has a valid claim to that account?

The obvious mechanism in my view is to use DNS based discovery of an
authentication service. For example, we might use the ESRV scheme I have
been working on:

_auth._ws.example.com  ESRV 0 prot "_saml._ws"
_auth._ws.example.com  ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols
may be used to resolve authentication requests.

One major advantage of this approach is that it makes it easy for sites to
move to using the new federated auth scheme. Most sites already store an
email address that is used to validate the account.

The actual mechanism by which the authentication claim is verified is not
very interesting, nor does it particularly need to be standardized. What
does require standardization is the ability to embed the protocol in 'the
Web' in a fluent and secure manner.

Here is how I suggest this be achieved:

1) HTTP header

The Web browser attaches an offer of authentication by means  of an account
attached to a specific domain to (potentially) every request:

Auth-N: domain=example.com

If the server does not support Auth-N, the header will simply be ignored.
Otherwise  the server can ask for automated authentication.

2) HTTP Response

If the server decides to use the authentication mechanism, it responds with
information that tells the client what level of authentication is required.
For example, a bank might require a 2 factor scheme. There is going to be at
a minimum a nonce.

Auth-N: snonce=<128bits>

3) HTTP Request

It should be possible for the client to prove that it has ownership of the
authentication token corresponding to the account.

It is not necessarily the case that the account owner wants to reveal to the
site all their information. For example, it may not even want the site to
know the account name. This is all fairly easy to set up using symmetric
techniques.

Auth-N: domain=example.com; blindedaccount=<> snonce=<128bits>;
cnonce=<128bits>

One feature that the OpenID work has highlighted the need for is some form
of user directed account manager. If the user is going to be in control of
this process, they need to be able to specify what information is made
available to specific sites.

Conclusion:

I think that what we require here is not yet another authentication
framework or protocol. What we need is the glue to bind it into an
infrastructure that makes it useful.

The most important design decision is to make use of RFC822 email address
format as the format for federated authentication accounts.

Once that decision is made, the rest will simply fall out of stating the
requirements precisely.

The risk here is that yet again we end up redo-ing the parts that we know
how to build rather than focus on the real problem which is fitting them
together.

Above all, the user has to be the first priority in any design.

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Dec 2010 00:12:02 +1300

I think we need to go a bit further and consider the issue of trust.

one problem with delegating account-holding back to a domain under
the control of the account-holder, is you have no trust.  I could be
[email-masked] or [email-masked].  I can set up whatever
account I like.  Websites have no information about whether I'm
trustworthy or not, and have to build up their own individual
profile of me.

To be really useful, the account-holding must be with a trusted
independent organisation able to be relied on by other websites.

The organisation then has the opportunity to add value by

a) verifying the true identity of the account holder

b) maintaining reputation information about the account holder

c) revoking abusive accounts.

Ends up looking a lot like X.509 certificate infrastructure.
Imagine if everyone needed a client certificate to send any mail.
We'd have no spam.

Of course these sorts of concepts are completely unpalatable to many
people on account of privacy issues. Some of these activities are
the sort of things that governments should really be doing (and
already are in many cases).

Solving this problem has implications for all internet use, not just
HTTP.

Regards

Adrien

On 19/12/2010 5:48 a.m., Phillip Hallam-Baker wrote:

I think that we need to distinguish between an
authentication mechanism and an authentication infrastructure.

Part of the problem with HTTP authentication is that it was
quickly superseded by HTML based authentication mechanisms. And
these in turn suffer from the problem that password
authentication fails when people share their passwords across
sites, which of course they have no choice but to do when every
stupid web site requires them to create yet another stupid
account.

Since Digest Authentication became an RFC, I don't think
there has ever been more than about 6 weeks elapsed without
someone suggesting to me that we include SHA1 or SHA2 as a
digest algorithm. Which is of course pointless when the major
flaw in the authentication infrastructure is the lack of an
authentication infrastructure. The original reason for designing
Digest the way that I did was that public key cryptography was
encumbered. Had public key cryptography been available, I would
have used it.

By authentication infrastructure, I mean an infrastructure
that allows the user to employ the same credentials at multiple
sites with minimal or no user interaction. I do not mean a
framework that allows for the use of 20 different protocols for
verifying a username and password.

We do have almost as many proposals for federated
authentication as authentication schemes of course. But each
time there seems to be an obsession with things that technocrats
obsess about and at best contempt for the actual user.

OpenID almost succeeded. But why on earth did we have to
adopt URIs as the means of representing a user account? And why
was it necessary to design a spec around the notion that what
mattered most in the design of the spec was the ability to hack
together an account manager using obsolete versions of common
scripting languages?

Another feature of that debate I cannot understand is why we
had to start talking about 'identity' as if it was some new and
somehow profound problem that had only just been discovered.

There is of course a standard for representing federated user
accounts that has already emerged on the net. And once that is
realized, the technical requirements of a solution become rather
obvious.

As Web sites discover that their account holders cannot
remember their username, most have adopted email addresses as
account identifiers. That is what we should use as the basis for
federated web authentication.

So if the user account identifier looks like [email-masked],
how does an entity verify that a purported user has a valid
claim to that account?

The obvious mechanism in my view is to use DNS based
discovery of an authentication service. For example, we might
use the ESRV scheme I have been working on:

_auth._ws.example.com
ESRV 0 prot "_saml._ws"

_auth._ws.example.com
ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in
XML) protocols may be used to resolve authentication requests.

One major advantage of this approach is that it makes it easy
for sites to move to using the new federated auth scheme. Most
sites already store an email address that is used to validate
the account.

The actual mechanism by which the authentication claim is
verified is not very interesting, nor does it particularly need
to be standardized. What does require standardization is the
ability to embed the protocol in 'the Web' in a fluent and
secure manner.

1) HTTP header

The Web browser attaches an offer of authentication by means
of an account attached to a specific domain to (potentially)
every request:

If the server does not support Auth-N, the header will simply
be ignored. Otherwise  the server can ask for automated
authentication.

2) HTTP Response

If the server decides to use the authentication mechanism, it
responds with information that tells the client what level of
authentication is required. For example, a bank might require a
2 factor scheme. There is going to be at a minimum a nonce.

Auth-N: snonce=<128bits>

3) HTTP Request

It should be possible for the client to prove that it has
ownership of the authentication token corresponding to the
account.

It is not necessarily the case that the account owner wants
to reveal to the site all their information. For example, it may
not even want the site to know the account name. This is all
fairly easy to set up using symmetric techniques.

Auth-N: domain=example.com;
blindedaccount=<> snonce=<128bits>;
cnonce=<128bits>

One feature that the OpenID work has highlighted the need for
is some form of user directed account manager. If the user is
going to be in control of this process, they need to be able to
specify what information is made available to specific sites.

Conclusion:

I think that what we require here is not yet another
authentication framework or protocol. What we need is the glue
to bind it into an infrastructure that makes it useful.

The most important design decision is to make use of RFC822
email address format as the format for federated authentication
accounts.

Once that decision is made, the rest will simply fall out of
stating the requirements precisely.

The risk here is that yet again we end up redo-ing the parts
that we know how to build rather than focus on the real problem
which is fitting them together.

Above all, the user has to be the first priority in any
design.

---

From: Nathan <[email-masked]>
Date: Sun, 19 Dec 2010 13:47:06 +0000

Hi Adrien, All,

What you describe sounds very much like WebID Protocol (formerly 
FOAF+SSL) - there's an incubator group just starting at the W3C [1] 
although the protocol [2] has been under development for some time.

Essentially it leverages X509 certificates on the client side, which 
contains an identifier (in the form of a URI) which can then be 
dereferenced to machine readable data (containing the public key from 
the x509 and any other data the entity wishes to expose), it serves as 
decentralized stateless authentication / identification, compatible with 
and built on the deployed stack of internet technologies, and further 
enables all kinds of trust & reputation hooks.

cc'd: Henry Story, foaf-protocols

[1] http://bblfish.net/tmp/2010/12/15/webid-charter-draft.html
[2] http://getwebid.org/spec/drafts/ED-webid-20100809/index.html

Best,

Nathan

Adrien de Croy wrote:
> one problem with delegating account-holding back to a domain under the control 
> of the account-holder, is you have no trust.  I could be [email-masked] or 
> [email-masked].  I can set up whatever account I like.  Websites have no 
> information about whether I'm trustworthy or not, and have to build up their own 
> individual profile of me.
> 
> To be really useful, the account-holding must be with a trusted independent 
> organisation able to be relied on by other websites. 
> 
> Ends up looking a lot like X.509 certificate infrastructure.  Imagine if 
> everyone needed a client certificate to send any mail.  We'd have no spam.
> 
> Of course these sorts of concepts are completely unpalatable to many people on 
> account of privacy issues. Some of these activities are the sort of things that 
> governments should really be doing (and already are in many cases).
> 
> Solving this problem has implications for all internet use, not just HTTP.
> 
> Regards
> 
> Adrien
> 
>> I think that we need to distinguish between an authentication mechanism and an 
>> authentication infrastructure.
>>
>> Part of the problem with HTTP authentication is that it was quickly superseded 
>> by HTML based authentication mechanisms. And these in turn suffer from the 
>> problem that password authentication fails when people share their passwords 
>> across sites, which of course they have no choice but to do when every stupid 
>> web site requires them to create yet another stupid account. 
>>
>> include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when 
>> the major flaw in the authentication infrastructure is the lack of an 
>> way that I did was that public key cryptography was encumbered. Had public key 
>> cryptography been available, I would have used it.
>>
>> user to employ the same credentials at multiple sites with minimal or no user 
>> interaction. I do not mean a framework that allows for the use of 20 different 
>> protocols for verifying a username and password.
>>
>>
>> authentication schemes of course. But each time there seems to be an obsession 
>> with things that technocrats obsess about and at best contempt for the actual 
>> user.
>>
>> So if the user account identifier looks like [email-masked] 
>> <mailto:[email-masked]>, how does an entity verify that a purported user 
>> has a valid claim to that account?
>>
>> authentication service. For example, we might use the ESRV scheme I have been 
>> working on:
>>
>> _auth._ws.example.com <http://ws.example.com>  ESRV 0 prot "_saml._ws"
>> _auth._ws.example.com <http://ws.example.com>  ESRV 0 prot "_xcat._ws"
>>
>> move to using the new federated auth scheme. Most sites already store an email 
>> address that is used to validate the account. 
>>
>>
>> The actual mechanism by which the authentication claim is verified is not very 
>> interesting, nor does it particularly need to be standardized. What does 
>> require standardization is the ability to embed the protocol in 'the Web' in a 
>> fluent and secure manner.
>>
>> Auth-N: domain=example.com <http://example.com>
>>
>> For example, a bank might require a 2 factor scheme. There is going to be at a 
>> minimum a nonce.
>>
>> Auth-N: snonce=<128bits>
>>
>>
>>
>> 3) HTTP Request
>>
>> site all their information. For example, it may not even want the site to know 
>> the account name. This is all fairly easy to set up using symmetric techniques.
>>
>> Auth-N: domain=example.com <http://example.com>; blindedaccount=<> 
>> snonce=<128bits>; cnonce=<128bits>
>>
>>
>> One feature that the OpenID work has highlighted the need for is some form of 
>> user directed account manager. If the user is going to be in control of this 
>> process, they need to be able to specify what information is made available to 
>> specific sites.
>>
>>
>> Conclusion:
>>
>> I think that what we require here is not yet another authentication framework 
>> or protocol. What we need is the glue to bind it into an infrastructure that 
>> makes it useful.
>>
>> The risk here is that yet again we end up redo-ing the parts that we know how 
>> to build rather than focus on the real problem which is fitting them together. 
>>

---

From: Ben Laurie <[email-masked]>
Date: Sun, 19 Dec 2010 21:49:56 +0000

On 19 December 2010 11:12, Adrien de Croy <[email-masked]> wrote:
> Imagine if

Nonsense. We'd just restrict spam to owned machines, of which there
are only a few tens or hundreds of milliions, if we're lucky.

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Dec 2010 11:06:32 +1300

On 20/12/2010 10:49 a.m., Ben Laurie wrote:
> On 19 December 2010 11:12, Adrien de Croy<[email-masked]>  wrote:
>> Imagine if

only if no-one revoked their certificate.

---

From: Marsh Ray <[email-masked]>
Date: Sun, 19 Dec 2010 22:04:40 +0000

> are only a few tens or hundreds of milliions, if we're lucky.

Nonsense. We'd have no mail. Or rather some other store-and-forward 
messaging system would arise and not be called mail.

Look back far enough and you'll find all kinds of "electronic mail" 
services implementing the full range of peer and end user 
authentication, and sender-pays models. There was no spam on those 
systems, or at least not enough that anyone felt like they needed a word 
for it.

Guess why we use the one we use today.

- Marsh

---

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Dec 2010 10:50:09 +0000

On 20 December 2010 09:25, Josh Howlett <[email-masked]> wrote:
>> username, most have adopted email addresses as account identifiers.
>> That is what we should use as the basis for federated web
>> authentication.
>
> Unfortunately this approach transgresses the fourth Law of Identity: 'Directed Identity'.
>
> "A universal system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles"

Of course these are not actually laws, just good ideas.

However: the core failing seems to be the requirement that users
should remember any more than their one "master identity" which is
used to store all the others (see my Nigori work for how).

>
> Josh.
>
> 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: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 02:08:38 +0000

On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey Hutzelman <[email-masked]> wrote:

> On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote:
>
> >
> > So if the user account identifier looks like [email-masked], how
> > does an entity verify that a purported user has a valid claim to that
> > account?
> >
> >
> > authentication service. For example, we might use the ESRV scheme I
> > have been working on:
> >
> >
> > Which declares that the SAML and 'XCAT' (presumably kitten in XML)
> > protocols may be used to resolve authentication requests.
> >
>
>
> I see two fundamental technical problems with this approach:
>
> 1) It relies on unsecured DNS to be secure.  Particularly, you suggest
> that, in order to discover a means to securely authenticate users
> associated with some entity with which I have no prior relationship, I
> should look up information about that entity in the DNS.  But DNSSEC is
> not widely-deployed enough (yet) for that to be realistic.  Further, I'm
> generally opposed to schemes that rely on the integrity of the DNS to
> secure applications, because, at the enterprise level and below, the
> operators of the DNS are frequently not entrusted with the security of
> applications.  I mistrust any system which insists on forcing that to
> change, while providing no recourse to those for whom such a policy is
> unacceptable (and no, "advertise in the DNS whether to use the DNS" is
> not such a recourse!).
>

No, there is no reliance on DNSSEC here, ideally the relationship is
authenticated end-to-end using an EV cert.

DNSSEC would be acceptable however.

> 2) It makes the assumption that my email service provider is interested
> in providing authentication services to me, and that I'm interested in
> giving them the ability to impersonate me to my bank.
> >
> >
>

Again, no.

The assumption is that you will choose an authentication provider that may
or may not be your current email provider. It is assumed that there will be
certain email forwarding taking place - at the account holder's discretion.

But if you use lame.com as your email you would end up going somewhere else
for your authentication if they won't support it.

I'd be much happier to see a model wherein, at registration time, I tell
> a service my public key, and then it uses public-key cryptography to
> authenticate me in the future.  Unfortunately, there are a number of
> practical problems there, such as dealing with multiple clients per
> user, kiosks, reinstalling machines, stolen credentials, etc., and it's
> really preferable to avoid having every service provider deal with those
> issues, rather than a much smaller number of authentication providers.
>

Raw public keys work less well than people think here.

A public key identifies a device, never a person. To make a binding to a
person you need infrastructure like I am describing here.

We are in the UK for Xmas, between the four of us we brought ten computers
(three laptops, on kindle, on iPad, two nintendo DS and three iPhones). Only
some of those devices are single user and four of the devices are shared by
all four of us.

So I would very much like to pair a federated authentication scheme for
people with a device level public key. I would also like to employ strong
two factor schemes that can be tied to device level keying. But client certs
alone do not serve this need.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 18:11:47 +0000

[We seem to have dropped off the mailing lists, Jeffrey suggested I post
this which shows where we ended up.]

On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelman <[email-masked]>wrote:

> On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote:
>
> I don't follow.  Your example shows an advertisement to service
> providers that users from example.com can be authenticated to the SP by
> using one of two authentication services.
>

Yes, it is assumed that there is some means of authenticating this binding,
I did not specify what.

>  Unless I'm misunderstanding
> you, this is about how the SP knows who to trust, and _not_ about how
> the user's software talks to the user's identity provider.  Thus EV is
> really mostly irrelevant, since EV is about being able to make claims
> that are really only meaningful when the relying party is controlled by
> a human (the green bar is pretty, but I've yet to see an email server
> that evaluates users' credentials on the basis of what color location
> bar it sees).
>

You do not understand the purpose of EV then.

EV is about accountability. The green bar is displayed because the issuer
applied validation practices that ensure a measure of accountability.

> So, to accept a user's credentials, the SP needs to know two things:
> 1) Is the assertion of user identity authentic?
> 2) Does the assertion of user identity come from an authorized entity?
>
> The answer to (1) is provided by the authentication protocol in use,
> which may well be public-key based.  But that's not the part I'm worried
> about.
>
> I am worried about (2).  You show an example of one way to answer part
> or all of (2).  But you don't show how that answer is itself
> authenticated.  DNSSEC is certainly an acceptable answer to that, modulo
> a whole bunch of conditions and issues that I'm willing to handwave
> away, for now.  But I don't think it can be the _only_ answer, for
> reasons I've already raised.  So, what's the other answer?
>

If there is a federated mechanism, there is going to have to be some
registry of federation points available somewhere. We could use
fred#facebook, jim#google and so on. But if there are friendly user
identifiers and multiple auth providers there are going to be multiple
repositories to disambiguate.

So there is going to be some PKI involved however you do it.

My preference is to use DNS for the signaling layer and DNSSEC to
authenticate the in-zone data. How you authenticate the server when you
arrive at it is another matter entirely.

My view is that authentication providers should be considered to require
substantial levels of infrastructure and planning. I totally reject the view
floated in OpenID that it should be a design requirement that some fred in a
shed can whack an authentication provider together from some Perl scripts
without even bothering to upgrade to a recent version of perl.

> Raw public keys, usually wrapped in the completely unnecessary trappings
> of a self-signed certificate, work surprisingly well in a wide variety
> of circumstances.  But they basically require first-order one-to-one
> relationships between every client and every service provider, with all
> the trappings required to deal with loss or compromise of the key, and
> that simply doesn't scale to the Internet.

CardSpace works perfectly well as a method of authenticating the client to
the authentication service. Less well as a means of federated
authentication.

Various people have proposed 'CardSpace' in the cloud. Which sounds really
convincing until you realize that they have not thought the problem through
at all.

> > To make a binding to a person you need infrastructure like I am
> > describing here.
> >
> Not necessarily.  I could imagine an infrastructure in which a user
> authenticates to some key-management service, which then hands the user
> his private key (the key belongs to the user, not the key-management
> service, so revealing it to the user is OK).  The user then uses that
> key for authentication with whatever other services he wants.  In fact,
> to services other than the key-management service, this is
> indistinguishable from the user having had the key all along.  Of
> course, it does involve the user handing his private key to some other
> service, which has its own problems.
>

I don't like that approach because in my view a private key is something
that should only ever exist in one place where it is created and later
destroyed.

I prefer an approach where the client-authentication provider authentication
uses whatever tool is best and then the authentication provider supplies
some form of token that can be used for authentication to at least one third
party.

That token could use public key, but symmetric is sufficient and more
efficient.