Subject: [http-auth] 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: Marsh Ray <[email-masked]>
Date: Fri, 10 Dec 2010 17:54:27 -0600

> Is it time to start thinking about next-generation authentication

No? :-)

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

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.

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?

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.

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?

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.

Improving the "authentication" for a protocol lacking basic message 
integrity would just be giving a false sense of security. It's like 
improving the login authentication for telnet or FTP sessions.

But I do think there are lots of improvements waiting to be made in the 
right directions.

- Marsh

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 10 Dec 2010 18:59:49 -0800

> within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt

I think http://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04 is the most recent iteration on the concept.  This is at the TLS layer, not the http layer.

As Paul Hoffman said, X.509 client cert's.  In fact one could argue that's the traditional solution and that software support is already widely available.  Some organizations make this more practical by issuing the client certs with KX509.  http://tools.ietf.org/search/draft-hotz-kx509-01 (-; Comments are still desired! ;-)

http://tools.ietf.org/html/rfc4559 (Microsoft's HTTP-Negotiate)  Note that W7/2K8 add channel binding to that, but it's an incompatible upgrade, so it may not get the use it should.

There is also active work in the abfab wg which is related.  Please try to synergise, not compete with that work.

SAML Web-sso

----

IMO there are already enough options which don't do channel binding with the enclosing TLS session.  I believe any solution you propose should either do that, or should operate as part of TLS itself.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 10 Dec 2010 23:21:18 -0600

> within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt

I have this:

draft-williams-tls-app-sasl-opt-04.txt

which could easily be made usable from HTTP.

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

One more list...  :)

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Dec 2010 01:10:11 +0200

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

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

At the time, the TLS working group (and an AD) told us that this would contradict the applicability statement of EAP, so no, you cannot use EAP for anything other than network access. 

Now we have the abfab working group, so I don't think this still holds.

Also, I agree with Marsh, that authentication is not enough, and you need the rest of TLS anyway.

So yes, I think that it is time to resurrect HTTP authentication.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Dec 2010 01:15:51 +0200

resending with less recipients...

---

From: Luke Howard <[email-masked]>
Date: Sun, 12 Dec 2010 12:38:07 +1100

> 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: Yoav Nir <[email-masked]>
Date: Sun, 12 Dec 2010 16:22:23 +0200

EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETER infrastructure. 

On Dec 12, 2010, at 4:10 PM, Alexey Melnikov wrote:

> 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:
>> 
>>>> 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.
>>>> 
> Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 00:06:29 +0200

Because I'd rather not implement too many mechanisms in my browser or in my web server.

And if EAP integrates better with RADIUS, while SASL integrates better with LDAP, it's still bad design to expose the server's backend to the client by the authentication protocol.

Let's try and list the requirements for HTTP authentication:
- It has to be integrated in the protocol, not the application
- 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.

On Dec 12, 2010, at 11:36 PM, Eliot Lear wrote:

> Why settle for one?
> 
> On 12/12/10 7:40 PM, Alexey Melnikov wrote:
>> Yoav Nir wrote:
>> 
>> 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: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Dec 2010 17:10:30 +0300

---

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

True.

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: Eliot Lear <[email-masked]>
Date: Sun, 12 Dec 2010 22:36:01 +0100

Why settle for one?

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 12 Dec 2010 09:29:39 +0200

Hi Luke,

As far as I can see 

Thanks,
	Yaron

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 12 Dec 2010 15:46:03 -0700

[Trimming the cc list.]

> holes and tell us what not to implement.

I like the idea of experimentation and then standardization. That's how
we've gotten most of our successful technologies so far. :)

Peter

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

---

From: Marsh Ray <[email-masked]>
Date: Sun, 12 Dec 2010 18:49:07 -0600

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?

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 12 Dec 2010 18:50:40 -0700

[Trimming the copied lists to just http-auth.]

> something at another layer which would have less risk than building on

Unfortunately, client-side certificates (or other means to enable
password-free authentication) have seen very little deployment outside
of specialized environments. Do you see that changing at all? If so, how?

> ecosystem because it widens the field for cross-protocol attacks.

By "cross-protocol attack" do you mean an attack that attempts to crack,
say, credentials for both a web service and an email service?

Peter

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

---

From: Marsh Ray <[email-masked]>
Date: Sun, 12 Dec 2010 21:02:21 -0600

On 12/12/2010 07:50 PM, Peter Saint-Andre wrote:
> of specialized environments.

Yeah.

> Do you see that changing at all?

I don't see why not. It's an interesting question.

> If so, how?

It could probably change if there were a large enough demand for it. 
There are a few speed bumps that are restricting TLS client cert auth, 
but most of them don't seem that major. Certainly there have been much 
greater problems solved in network security when there was motivation to 
do it.

My understanding is that a lot of smart phones are using client certs 
under the hood. Some financial web sites, card-access systems, and so 
on. So it is certainly possible.

Client certs are weird because they don't identify the computer (they're 
just files that can get copied) and they don't identify the user like a 
password (the user can't easily use them from another machine without 
copying them). They currently require that a file be downloaded and 
installed. The web browser could automate most of this better, but if it 
were made completely seamless, then how would it be all that different 
than a secure cookie?

> say, credentials for both a web service and an email service?

I mean: User connects to insecure Wifi and attempts to log in to 
corporate VPN, bad guy intercepts the VPN protocol authentication and 
uses it to establish a connection to secure https site with the 
credentials of the legitimate user. Or vice-versa. Or IMAP and SMB, you 
name it.

The most obvious example is a plaintext password. If the client can be 
tricked into giving up a plaintext password, the attacker can use that 
almost anywhere at a later time. Every time someone installs a new 
telnet-like client application, it weakens the effective security as 
seen by their SSH server.

Some common challenge-response protocols only make marginally harder 
than the plaintext password: the bad guy has to intercept the TCP 
connection and execute the attack right when the client is on line and 
willing to authenticate. If the raw hash calculations of the 
authentication are compatible, and it fails to "bind" specifics like 
server name and port number strongly into those calculations, then under 
the right conditions an attacker can forward the authentication to a 
completely different server, possibly using a different application 
protocol.

Something like NTLM which can be used by clients or servers on a dozen 
or more application protocols has literally hundreds of potential 
combinations of client and server protocols for an attacker to mix and 
match between independently. The first vulnerable combination with NTLM 
was demonstrated over ten years ago and a dozen or so CVEs later, 
they're still finding new ones.

- Marsh

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Dec 2010 10:11:10 +0300

>we've gotten most of our successful technologies so far. :)
+1.

My major concern in this case is that I think we might have too many 
proposals already. That is why I was talking about criteria for deciding 
which to keep.
These would also help security experts to decide what to look for. No 
security is perfect in all cases and people can live with non-perfect 
security as long as threats are well understood. If we just ask "find 
all possible holes in these proposals", we might end up with no 
proposals to pick from ;-).

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 10:49:08 +0200

>> experts could define something perfect.  Zero progress so far.

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.

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Dec 2010 12:29:46 +0100

And here-in lies the problem: I am concerned that in a large group we
will not be able to reduce down to a single requirements list – AT THIS
TIME.  Also- my own experience is that having some decent proposals in
front of you often helps drive at least SOME consolidation.

---

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: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 15:08:40 +0200

> HTML/CSS/JS lends itself well to providing such a friendly user interface.

Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari).  So if we invent <input type="password_2.0" />, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ?

> Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding.

Agree.

> 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 bindi…

I don't think the security requirements can be met using this (although I'd love to hear differently from browser people). Maybe if we could customize the authentication dialog with some kind of icon (like favicon), and maybe a frame or a div with some HTML elements (buttons, links).  I am not a UI expert (IANAUIE ?) but I think it's important that user authentication be quite distinct from the rest of the flow. IOW the user should know that at this point, she is not just surfing, but actually authenticating to a particular server, and if she's ever presented with some web form that says "username:_______ password:_______" she's going to know that something is wrong.

> We'll need the browser people to start any such effort.

Fully agree. We really need to hear from both browser people and web application developers. No point in designing something really secure if the people in google/amazon/BOA then say "no, we'll never use that"

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Dec 2010 14:46:02 +0100

> HTML/CSS/JS lends itself well to providing such a friendly user interface.

On the other hand, that's what you have today.  What is it you want for
tomorrow?

Eliot

---

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:
> On Sun Dec 12 22:06:29 2010, Yoav Nir wrote:
> 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
>>
> SASL also has methods that will do this, I think - I'm not sure what 
> additional layer you're referring to here.
>
> Dave.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 13 Dec 2010 15:16:56 +0100

Yoav Nir wrote:
> And if EAP integrates better with RADIUS,

  It's more "already integrated with RADIUS", and "RADIUS integrates
with LDAP".

> while SASL integrates better with LDAP, it's still bad design to expose the server's backend to the client by the authentication protocol.

  EAP is already being transported over PPP, ethernet, RADIUS, Diameter,
and other transport/authentication protocols.  It's used because adding
it is easy, and it separates the authentication protocols from the
application.

  As for SASL, that's not my area.

  Alan DeKok.

---

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

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

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

---

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

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

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

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

---

From: Rene Struik <[email-masked]>
Date: Mon, 13 Dec 2010 09:15:31 -0500

Hi Yoav:

Could you summarize the main problems with client certificates. To my knowledge, there are no technical problems with computational bottlenecks on the client side yet. The only problem area I could think of would be storage of private keys, but this seems solvable.

Similarly, if you could point out main usability problems with certs that would be great (is this a general problem, or just an artifact of the way these are currently used?). Problems stem from realistic requirements not being met, so it is good to capture these.

Rene

==
[excerpt email Yoav Nir as of Monday December 13, 2010, 3:49am EST]

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Rene Struik <[email-masked]>
Date: Mon, 13 Dec 2010 09:24:34 -0500

Hi Yoav:

Could you summarize the main problems with client certificates. To my 
knowledge, there are no technical problems with computational 
bottlenecks on the client side yet. The only problem area I could think 
of would be storage of private keys, but this seems solvable.

Similarly, if you could point out main usability problems with certs 
that would be great (is this a general problem, or just an artifact of 
the way these are currently used?). Problems stem from realistic 
requirements not being met, so it is good to capture these.

Rene

==

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.

On 13/12/2010 3:49 AM, Yoav Nir wrote:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

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: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 17:29:17 +0200

On Dec 13, 2010, at 4:24 PM, Rene Struik wrote:

Hi Yoav:

I can see several problems with client certificates, most related to usability, but some also to security:

 *   Certificates do not authenticate the user. They authenticate a device. Placing a certificate on my laptop is a close enough approximation to authenticating *me*, but then I can't use the same certificate on my home computer, my phone, or the computer at some Internet cafe or hotel business center. Passwords, on the other hand, are with me wherever I go, and can be used with any device.
 *   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.
 *   While some places of business, governments and militaries are willing to spend the money and effort required to provision certificates for all employees, I don't see companies doing it for customers. It's never a good idea to bet that something is too big for Google to do, but I can't imagine them issuing client certificates to all gmail users. Even banks, with real money at stake don't do it, because the support costs would exceed the losses to phishing.
 *   Issuing certificates does not solve the problem with Internet cafes. It makes no sense for me to install a browser certificate on some random computer.

But don't take my word for it. Certificates are so inconvenient, that people would rather use some two-factor authentication solution, where you type in a password, and then get a one-time code on either a fob or through an SMS message to your phone, which is what Marsh's company does.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Dec 2010 17:32:53 +0200

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.

Thanks,
	Yaron

On 12/13/2010 03:08 PM, Yoav Nir wrote:
> Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari).  So if we invent<input type="password_2.0" />, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ?
>
>>
>> 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.
>

---

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: Yoav Nir <[email-masked]>
Date: Mon, 13 Dec 2010 17:50:52 +0200

On Dec 13, 2010, at 5:32 PM, Yaron Sheffer wrote:

> displays a JPEG-rendered padlock icon.

I don't know how to stop them, unless the "special" UI cue becomes so ubiquitous, that its absence causes the user to think, "wait a minute. This does not look like authentication!"

As long as every website has authentication that looks different and not different enough from regular web browsing, people are going to accept any web form as a legitimate authentication dialog.

> In fact *legitimate* sites have

---

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: Marsh Ray <[email-masked]>
Date: Mon, 13 Dec 2010 13:24:34 -0600

On 12/13/2010 09:29 AM, Yoav Nir wrote:
 >> Could you summarize the main problems with client certificates. To
 >> my knowledge, there are no technical problems with computational
 >> bottlenecks on the client side yet. The only problem area I could
 >> think of would be storage of private keys, but this seems
 >> solvable.
 >>
 >> Similarly, if you could point out main usability problems with
 >> certs that would be great (is this a general problem, or just an
 >> artifact of the way these are currently used?). Problems stem from
 >> realistic requirements not being met, so it is good to capture
 >> these.
 >
 > * 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.

 > Placing a certificate on my laptop is a close enough
 > approximation to authenticating *me*, but then I can't use the same
 > certificate on my home computer, my phone,

Why not?

 > or the computer at some
 > Internet cafe or hotel business center.

But there's nothing that you can do securely on an untrusted computer. 
Sometimes people propose the idea of a secure boot CD users carry 
around, but those can't defend against trojaned firmware or hardware.

 > Passwords, on the other hand,
 > are with me wherever I go, and can be used with any device.

They have some pretty significant limitations too.

 > * 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,

N users, M sites. N is billions, M is millions.

N * M = a big number.

Perhaps if we accept it as an inherently complicated problem then we can 
give people tools that they need?

 > and increases the attack surface.

Honestly, could it be any worse?

 > * While some places of business, governments and militaries are
 > willing to spend the money and effort required to provision
 > certificates for all employees, I don't see companies doing it for
 > customers. It's never a good idea to bet that something is too big
 > for Google to do, but I can't imagine them issuing client
 > certificates to all gmail users.

Ha! I bet if we double-dog dared them, they just might.
Remember that they went all-TLS for gmail, when every other smaller site 
was saying it was un-economic.

 > Even banks, with real money at stake
 > don't do it, because the support costs would exceed the losses to
 > phishing.

My understanding is that some banks do, in fact, use client certs.

But from what I've seen, the economics and risk motivations of the 
banking sector are just really weird. It varies by country, and in the 
US it's still not entirely clear yet who's liable for losses due to 
online security. Banking is just so different than everyone else that 
it's usually not helpful to use it as an example it in general security 
discussion.

 > * Issuing certificates does not solve the problem with Internet
 > cafes. It makes no sense for me to install a browser certificate on
 > some random computer.

Again, there's nothing you can do to make a login session secure from an 
untrusted machine.
Perhaps we should throw this scenario out for the purposes of this 
discussion?

 > But don't take my word for it. Certificates are so inconvenient, that
 >  people would rather use some two-factor authentication solution,
 > where you type in a password, and then get a one-time code on either
 > a fob or through an SMS message to your phone, which is what Marsh's
 > company does.

The key thing is that the phone is something most people already have 
and are comfortable using. It's hard to overstate the value of that.

Nevertheless, what we (well, Marketing in particular :-) are continually 
up against is this: on some level, the entire purpose of strengthening 
the authentication is to make it harder to log in to the computer. We 
can do our best to minimize how much harder it is for the legitimate 
user, and maximize how much harder it is for the bad guy, but at the end 
of the day the system ends up having more ways to say 'no'. For most 
systems, the vast majority of 'no's are not actual attacks.

Theatrics that don't provide real security are obviously worthless, but
so are strong systems that people don't use. This trade-off between 
security and usability is very real, not theoretical.

Perfect example:

On 12/13/2010 06:14 AM, Carsten Bormann wrote:
 >
 > 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.

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?

(These are rhetorical questions.)

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

Right. Any time there's an untrusted app painting into a rectangle (e.g. 
the browser window) the only ways to communicate with the user securely 
is outside of that rectangle. Which is why the URL and lock icon are in 
the browser chrome (and why we're in the out-of-band authentication 
business). As people use more mobile devices with smaller screens, this 
chrome gets mostly optimized away (and may confuse the degree to which 
the phone is truly out-of-band).

There's clearly a large set of users for whom this "rectangle" principle 
is too complicated. (It probably doesn't help that browsers allow web 
pages to open new windows, set the title bar and icon, and that they 
repurpose the untrusted rectangle to discuss certificate errors.)

The most secure way I've seen to handle password entry is (don't laugh) 
MS Windows NT through Vista. Windows NT implemented Orange Book security 
and required a "secure attention key" sequence (ctrl+alt+del) before 
every password request. Vista UAC, though a failure in many ways, would 
switch the entire console session, going so far as to reinitializing 
hardware drivers in the process. It performs a whole-screen dimming 
effect which was said to be difficult to duplicate (I'm not sure in 
practice).

So IMHO, significant improvements in web authentication would be greatly 
beneficial. But they will have to:

* Require connection integrity. This probably means mandatory TLS.

* Require a user interaction that takes place outside the insecure 
browser rectangle and feels different enough that it's easy to explain 
the difference.

* Not leak info to untrusted parties. These days privacy is often more 
important than traditional security.

* Support browser vendors in making a UI that "sucks less" to have to 
use, or possibly have to use it less. Put users in control of their 
identity and auth credentials without nagging them repeatedly until they 
give in and click the "Yes to all" button.

* Represent an actual improvement in security over the current standard 
of HTML form POST password and secret HTTP session cookie.

- Marsh

---

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 13 Dec 2010 15:00:46 -0800

> of HTML form POST password and secret HTTP session cookie.

+1

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 13 Dec 2010 15:03:29 -0800

> portability if we want people to use them.

I think it's a "complete system" problem.

You need a decent UI paradigm (not just a GUI), a respectable means of issuing/deploying them, a respectable means of storing them for use by multiple applications, and APIs and hooks that make them as easy to develop with as cookies.  Also all the capability needs to already be in place, so there's no "plug-in installation" or equivalent.

By "respectable" I mean something a security expert won't laugh at, which doesn't also violate the UI paradigm.

For all the people who say that we don't have to have perfect security, or we need to support http:, not just https:, I respectfully claim that you're off base.  We don't need *more* less-than-secure mechanisms.  We need actually-secure mechanisms that real people can actually use.

TLS with client certs qualifies as "actually-secure" (as would TLS with draft-williams..sasl..04).  Wouldn't we be better off putting our energy into making it actually-usable, than in starting from scratch?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Dec 2010 17:17:08 -0600

> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equivalent?

_I_ believe it does :)

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Dec 2010 17:18:36 -0600

On Sun, Dec 12, 2010 at 09:29:39AM +0200, Yaron Sheffer wrote:
> 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):

You missed the ABFAB thing...  ABFAB WG is producing [drumroll please] a
GSS-API mechanism that uses EAP.  And SASL can use GSS mechanisms (via
"GS2" [RFC5801]).

So, I believe that the answer is "yes".

Nico
--

---

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:
> 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: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Dec 2010 10:37:37 -0700

[removing all those other lists from the cc's, please do the same]

On 12/13/10 4:03 PM, Henry B. Hotz 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.
>> 
> You need a decent UI paradigm (not just a GUI), a respectable means
> of issuing/deploying them, a respectable means of storing them for
> use by multiple applications, and APIs and hooks that make them as
> easy to develop with as cookies.  Also all the capability needs to
> already be in place, so there's no "plug-in installation" or
> equivalent.
> 
> By "respectable" I mean something a security expert won't laugh at,
> which doesn't also violate the UI paradigm.
> 
> For all the people who say that we don't have to have perfect
> security, or we need to support http:, not just https:, I
> respectfully claim that you're off base.  We don't need *more*
> less-than-secure mechanisms.  We need actually-secure mechanisms that
> real people can actually use.
> 
> TLS with client certs qualifies as "actually-secure" (as would TLS
> with draft-williams..sasl..04).  Wouldn't we be better off putting
> our energy into making it actually-usable, than in starting from
> scratch?

That sounds ideal, but difficult. Do we have any pointers toward how to
make client certificates a success? Examples in particular communities
or from other technologies (e.g., IMAP, XMPP)? Best practices that we
can build on?

Peter

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

---

From: Tim Morgan <[email-masked]>
Date: Tue, 14 Dec 2010 09:12:50 -0800

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.

> 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: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 11:58:22 -0600

[Dropping extraneous lists.]

> in the next layer up (POST requests/cookies) is even worse.

You're surely referring specifically to HTML forms beign POSTed.  That'd
be one form of authentication above HTTP -- a bad one.  But not
necessarily the only one!

For example, one could use POST and GET to implement a SASL or GSS-API
context token exchange over HTTP, complete with channel binding to TLS.
I call this "GSS-REST" :) and it would still use TLS and [secure]
cookies (can't be authenticating every request), just not passwords sent
in the clear relative to the TLS layer (assuming one weren't using SASL
PLAIN, which one indeed should not).

GSS-REST isn't exactly round-trip optimal, but it does leave HTTP alone
and unmodified.

Whereas doing something more like HTTP with TLS/SA (draft-williams-tls-
app-sasl-opt-04) once, exporting the state of authentication to the
application, and letting the application manage cookies so that
subsequent HTTP requests need only TLS (with the same server cert) would
be round-trip optimal, and it'd barely modify HTPP (in that the TLS/SA
authentication state has to be communicated to the app, but this is
already true of DIGEST-MD5 today).

> even just Basic auth alone adds state.  Cookies add state, and we have

But cookies can be and are implemented by the layer above HTTP.  HTTP is
stateless.  HTTP applications often are NOT stateless.

> > providing real integrity?

A lower layer is clearly necessary, and it is and must remain TLS (or
TLS/SA).

Nico
--

---

From: Tim Morgan <[email-masked]>
Date: Tue, 14 Dec 2010 10:44:36 -0800

Hi Nicolas,

> already true of DIGEST-MD5 today).

I am a firm believer that we need to get away from cookies for
authenticated session management.  They are badly defined, even more
poorly implemented by browsers, and in my experience are leaving web
developers open to attacks in nearly every deployment.  For more
information, see:
  http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html

and as I posted earlier, my own arguments:
  http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

Of course you can always say that you'll define a protocol in such a
way to avoid these problems, but you have competing business drivers
in how cookies are used, so I suspect protocol implementations which
use them will continue to be problematic for a long time.

> stateless.  HTTP applications often are NOT stateless.

Ok, well I'm not going to argue where the dividing lines are in your
definitions.  I'm a security expert, not a standards expert.  Also,
the most important parts of my email you didn't respond to, so I'm not
going to highlight this point by arguing it.

> A lower layer is clearly necessary, and it is and must remain TLS (or

Sure, that I agree with.  That's why if authentication is done in
HTTP, it only needs to be light weight enough to provide good
authentication, not full channel security.

Regardless of whether or not authentication is done at the HTTP or TLS
layers, it needs to be something that can be utilized with a
customizable login form and authentication workflow.  This would
include being able to reset user passwords/credentials, store state
associated with an authenticated session, have application-driven and
user-drive log outs, and a number of other things.  Many of the
roadblocks ot TLS-based authentication exist mostly in browser and
server implementations, but if there's even one limitation in the
standards that wouldn't allow for *all* of the current common use
cases (in cookie-based auth), then it's really hard to generate
momentum to make the browser and server implementations suck less.

tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 12:59:58 -0600

>   http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html

If you don't want cookies then application session state must correlate
strongly with TLS session state, which in turn means some amount of
change to HTTP, and possibly to TLS implementations as well (since it'd
be important to, for example, not re-use TLS session IDs without first
garbage collecting application session state.

I believe that cookies are here to stay, for better or worse, so I'd
rather focus on making their use more secure, which I believe is
possible.

>   http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

I'll make sure to read these.  Thanks for the links.

> use them will continue to be problematic for a long time.

Given that there are huge installed bases to work with, and much
migration effort to exert, I think business costs need to be part of the
picture.

> authentication, not full channel security.

Indeed.  But what do you mean by light-weight, besides the lack of
"security layers" and, possibly, key exchange capabilities?  The devil
is in the details...

For example, are you considering a small, bounded number of round-trips
to be necessary to meet the "light-weight" requirement?  What about
pluggable frameworks?  The use of pluggable frameworks effectively means
that naming of security entities will be mechanism-specific, which makes
things not light-weight -- but there's no one-size-fits-all
authentication mechanism, we need pluggable frameworks!

> customizable login form and authentication workflow.  This would

I agree with this.

> roadblocks ot TLS-based authentication exist mostly in browser and
                ^^^^^^^^^^^^^^^^^^^^^^^^
> momentum to make the browser and server implementations suck less.

Are you referring specifically to user certs?

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 11:41:58 -0800

>> customizable login form and authentication workflow.  This would

I'm not sure I do.  Someone had a nice discussion of why a secure authentication system needed to use the surrounding chrome, and not live inside the window where it can be spoofed.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 14:06:48 -0600

On Tue, Dec 14, 2010 at 11:41:58AM -0800, Henry B. Hotz wrote:
> >> Regardless of whether or not authentication is done at the HTTP or
> >> TLS layers, it needs to be something that can be utilized with a
> I'm not sure I do.  Someone had a nice discussion of why a secure
> authentication system needed to use the surrounding chrome, and not
> live inside the window where it can be spoofed.

The two are not mutually exclusive.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 14:13:23 -0600

> The two are not mutually exclusive.

Or, at least, it isn't obvious to me that the two goals are mutually
exclusive.

Nico
--

---

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: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 12:29:04 -0800

> The two are not mutually exclusive.

Right, so being a security geek, I totally agree with taking the login
interface out of the hands of web developers.  Let the user agent do
it, and at most allow the site to throw a logo on the interface.

But in reality, I don't see such a scheme being adopted.  Business
people who don't understand the technical implications will continue
to demand fully customizable GUIs for the login.  Security always is
an afterthought for most organizations.

All too often in standardization processes, I've observed (from the
outside) that way more is bit off than can be chewed.  I'd rather
focus on taking small steps that tangibly improve the security of the
most common implementations.  Trying to make the world switch off of
pretty login forms seems like too big of a piece to chew.

Several HTTP authentication methods already exist, some are quite
secure.  Why aren't we using them?  That's my motivation for going
down the path I went.  I found out that it is possible to have
HTML-based login forms for HTTP auth (spoofable, but a common biz
requirement) and browser-based login forms (more secure) in the same
web app.  This isn't a horrible compromise if we can get people off of
poorly conceived cookie-based systems.

tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 14:33:41 -0600

> an afterthought for most organizations.

Agreed.   That said, if they turn out to be mutually exclusive, _then_
I think we must dump login form customization.  Also, in terms of
specification and implementation cost, clearly it's cheaper to forego
customization.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 12:43:19 -0800

> Or, at least, it isn't obvious to me that the two goals are mutually

Possibly not.  

Whatever is done should be non-spoofable in a way that a casual, intelligent user can't ignore.  I think that implies the same level of modification to the browsers either way.

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 12:49:43 -0800

> garbage collecting application session state.

Correlating TLS state with application session state doesn't
necessarily require any change to HTTP.  It just requires application
server session frameworks to support client certificates and/or SRP.

Alternatively, if those frameworks supported existing HTTP
authentication standards, such as digest auth, then we'd also be in a
lot better shape than using cookies, as my paper argues.  However,
there's one huge roadblock to this:  HTTP authentication has no
standard/sane way to allow a user to log out.  It seems like a little
thing, but it is a requirement for most applications.

> rather focus on making their use more secure, which I believe is

Oh, cookies aren't going away, but we should seriously think about
moving away from them for authentication purposes.

> I'll make sure to read these.  Thanks for the links.

Yes, I suspect if you don't read my paper, you'll sucker me into
re-explaining everything I have in there, bit by bit. ;-)  

> migration effort to exert, I think business costs need to be part of the

When it comes to business costs for moving away from cookie-based
auth, I see the process as something like:

A. Standards are fixed to allow for the possibility of good
   alternatives

B. Web development frameworks eventually implement seemless session
   management based on these alternatives along side cookie-based
   sessions 

C. App developers can flip a switch to move from cookie-based to HTTP
   auth or TLS based sessions.

It's a long road, but need not involve a great deal of effort on the
part of most businesses.

> "security layers" and, possibly, key exchange capabilities?  The devil

By "light-weight" I merely meant to say that only the authentication
step needs to be implemented.  Not encryption, integrity, etc.  

> authentication mechanism, we need pluggable frameworks!

In my experience, frameworks usually stop at the point of being a
framework without any widespread implementations.  Marsh mentioned
that many of the features of SSL/TLS are not even being used.  Why?
People don't understand them.

It is so tempting to try and make software or standards "future
proof", but this rarely brings benefit where rubber meets the road.

> > roadblocks ot TLS-based authentication exist mostly in browser and

Client certs or SRP, yes.  As I mentioned elsewhere, I don't forsee
passwords ever fully going away.  SRP is a good way to secure them.
Wouldn't it be nice if we had session management built in to
application servers which actually supported both client certs and SRP
as equivalent forms of authentication?  

tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 12:51:18 -0800

On Dec 14, 2010, at 9:37 AM, Peter Saint-Andre wrote:

>> You need a decent UI paradigm (not just a GUI),

As other people have noted, we get nowhere unless the browser vendors sign up.  We also get nowhere unless it's simple enough that casual (but intelligent) users can figure it out.  Keeping it simple also makes it easier to implement.

I think we need to be more complex than a simple "lock" icon.

Some information that's probably needed:  Whether the credentials sent over the wire could be reusable or not.  Whether the connection is "secure" the way *we* define it.  Easy access to the authenticated client and server identities for the connection.  (Also a better selection process for the client ID to use. The current X.509 cert selectors stink.  Kerberos gives you no selection choice at all.)

>> a respectable means of issuing/deploying them,

KX509 has survived the lack of support from its originator (and I plan to update it once I finish the current draft).  I recall mention of proposals for smart phones, but don't know how secure they are.

>> a respectable means of storing them for use by multiple applications,

I assume the FIPS-140 storage used by Firefox would be good enough if it were multi-application.  Can it be spun into an independent pkcs11 library?  (Does pkcs11 itself need updating to make it usable?)

>> and APIs and hooks that make them as
>> easy to develop with as cookies.  

Obviously there are lots of web development platforms.  Is there a way to securely redefine cookies to make adoption easy?  (Need to digest Tim M's references.)  Do we even need cookies if we have client IDs from the TLS session?

>> Also all the capability needs to already be in place, so there's no "plug-in installation" or equivalent.

Obviously, this comes with time.  It can happen if the other factors work out.

If the browser UI updates are the big thing, then they probably get bundled with the protocol updates.

> make client certificates a success?

I think the UI is the hardest part.  How do we make client ID selection meaningful?  Any X.509 wonks (Peter S-A?) want to propose something that doesn't require the entire subject DN?  How do we distinguish X.509 IDs from Kerberos IDs from hijackable username/passwords?

> Examples in particular communities

I don't think it's (primarily) an http-protocol issue.

I think if people in this group have the horsepower to get a UI update into both Mozilla/Firefox and Webkit/Chrome(/Safari?), then we can succeed in a few years.  Otherwise I think we're just adding hooks that may be used in specific Enterprise deployments and it will take much longer.

Does this put me outside the scope of the charter?

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 12:56:45 -0800

> specification and implementation cost, clearly it's cheaper to forego

I (and people prior to me) have already shown that it is possible to
have HTTP-based authentication with both HTML login forms and via
traditional browser popups in the same app.  Check out the paper I
posted earlier and also my PoC implementation:
  http://vsecurity.com/download/tools/fbha-poc_0.1.zip

Now, sure, I'd love to see a variant of this which did TLS/SRP auth
via XMLHttpRequests instead of using HTTP auth, but that's much less
attainable with current software.

However, maybe we should be nudging Anne van Kesteren and her W3C crew
about adding some language to the XMLHttpRequest draft standard to
allow for client cert and SRP initiated authentication requests to be
handled in some way... 

tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 14:56:51 -0600

> poorly conceived cookie-based systems.

Well, let's see, we have:

 - HTTPS with user certs.

   Not used because... people tend to put useful information in user
   certs, and independently tend to need multiple validation paths,
   resulting in a multiplicity of certs, resulting in difficulty
   selecting one credential or another in any given context.  End
   result: ick.

 - DIGEST-MD5.

   Legacy.  MD5.  Ancient.  Not federated.  Ugly browser dialogs.  End
   of story.

 - HTTP/Negotiate

   Currently used only with Kerberos and NTLM.  Kerberos could be
   deployed on an Internet scale, but like a one-root PKIX PKI, never
   will be.  No need to explain why NTLM isn't taking over the Internet.

   Given recent work on HTTP/Negotiate and the ABFAB WG and possible new
   mechanisms from the KITTEN WG, we'll have many more mechanisms than
   just Kerberos and NTLM for use in HTTP/Negotiate.  I'm not sure that
   they'll be used extensively through HTTP/Negotiate -- that will
   depend on what else we do in terms of HTTP auth NG, no?

   Also, HTTP/Negotiate provides no generic way to customize credential
   selection and credential initiation forms/dialogs.  Such
   customization will generally have to be mechanism-specific -- and I
   expect that to be true for all cases where we use pluggable security
   frameworks.

Am I missing any other existing HTTP authentication schemes?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 15:08:32 -0600

> server session frameworks to support client certificates and/or SRP.

It requires that HTTP implementations pass the relevant TLS state/info
to the app.  If we were to add new things that HTTP implementations have
to pass along, then we'd be requiring changes to HTTP implementations,
even if not, strictly-speaking, changes to HTTP itself (I consider
abstract interfaces to be necessary parts of protocol specification).

And note that it's not just about exposing client certificates and or
names (in the SRP case), but also about exposing TLS session state (one
does not want to authenticate the user on every TLS handshake, but to
resume sessions whenever possible).

> thing, but it is a requirement for most applications.

Cookies do fix that problem...

> moving away from them for authentication purposes.

They're not used for authentication.  They're used to tie multiple
requests to an authenticated session.  Big difference.  Perhaps it's
just a matter of wording.

> People don't understand them.

TLS isn't a framework in the sense that I meant.  Are you familiar with
any of SASL, the GSS-API, or EAP?

> proof", but this rarely brings benefit where rubber meets the road.

This isn't about future proofing, but about not forcing a single
authentication credentials infrastructure choice on all users.  Further,
it's about allowing users to use the infrastructures that they have now,
such as Kerberos, PKI, and AAA.

> as equivalent forms of authentication?  

SRP is no panacea: it doesn't federate.  Whereas a federated
authentication mechanism such as the one ABFAB WG is building could use
SRP to mutually authenticate users and IdPs to each other, and then
build on that to authenticate users and relying parties to each other.

If your view of the solution is that we should all be using user certs
or SRP, well, I caution you to not be too surprised to see that approach
fail.  User certs have already failed.  SRP hasn't even been tried, and
when tried will almost certaily fail unless coupled with a federated
authentication system (see above).

Nico
--

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 13:16:37 -0800

>    selecting one credential or another in any given context.  End

Current software does make this painful.  I think it could be better,
just based on changes to client/server software for managing certs,
but ultimately you have the limitation that certs can't be memorized
by users (at least until we all have chips implanted in our brains).
Username/password pairs can be memorized.

>    Legacy.  MD5.  Ancient.  Not federated.  Ugly browser dialogs.  End

Back up.  Drop "legacy" and "ancient", as they aren't useful for a
technical discussion.  

MD5 is perfectly fine for the application.  Need I describe the
difference between preimage, second preimage, and collision attacks
against hashes?  These are three distinct attack scenarios, only the
first of which applies in this protocol.  Besides that, Digest auth
does allow for the possibility of other hash algorithms, though
additional ones are not currently defined.

Not federated... Well, it does allow for sessions generated in one
origin to be transferred to another origin.  That may not constitute
"federated", but it does allow for single sign-on scenarios, perhaps
for multiple sites within a single organization.   You can even pass
along encrypted session state between sites, sort of like cross-domain
cookies.  This is actually quite powerful and if used right and could
be used as a building block in more complex federated systems. 

Ugly browser dialogs: YES.  This applies to all HTTP auth mechanisms,
though I've shown that you can get around that, as I mentioned in
several prior emails.

Note that Digest also happens to be supported by most popular user
agents.

>    expect that to be true for all cases where we use pluggable security

I'm not as familiar with Negotiate, but yes, this could be quite good
as well, for certain applications.

> Am I missing any other existing HTTP authentication schemes?

I think there might be some other obsecure ones out there, but my
favorite is of course the draft Mutual standard.  It has one security
features that none of the others have, and arguably does better than
TLS client certificates when it comes to phishing.

thanks,
tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 15:31:57 -0600

> TLS client certificates when it comes to phishing.

What's the "draft Mutual standard"?

---

From: Marsh Ray <[email-masked]>
Date: Tue, 14 Dec 2010 15:47:55 -0600

>     selecting one credential or another in any given context.  End

Another is perhaps browsers are unwilling to authenticate with a client 
cert that they can't validate themselves. Which effectively means a 
browser has to trust the site's custom CA, or the site has to get its 
users into some kind of a commercial arrangement. Not very flexible.

But aren't these mostly solvable implementation details?

>     Legacy.  MD5.  Ancient.  Not federated.  Ugly browser dialogs.  End

Other than the recent upward trend towards openid, there didn't seem to 
be much demand for federated auth.

As for the ugly browser dialogs, is there anyone other than the browser 
vendors to blame?

What offends me more is when I follow an unremarkable link on the web, 
it unexpectedly requests authentication, so I hit cancel. I then get a 
really nasty error page basically accusing me of seeking unauthorized 
access. I can understand why no commercial site would want to do that to 
their users.

>     will be.  No need to explain why NTLM isn't taking over the Internet.

Yeah, it's not what people want.

Theory aside, it creeps people out that they would be be strongly 
authenticated everywhere they surf. I'm just not going to sign up with 
my drivers license or US passport officially legal credentials to leave 
a comment on some random blog. I'm not necessarily seeking anonymity either.

Schemes that expect users to sign up to a central registry are just not 
what people want.

What users seem to want is an easily-remembered password they can use 
all over the place. Hopefully we can get them something better.

What most web sites seem to want is an authentication scheme that they 
can customize according to their style and needs and never denies access 
to anyone plausibly legitimate. Often they don't even want the user to 
have to log in more than once, ever. They don't want the user to see 
another 50ms of latency or bear another 10% server CPU overhead for TLS. 
They want to be able to load Javascript from 5 different affiliates and 
marketing companies.

>     depend on what else we do in terms of HTTP auth NG, no?

Will any of that change what we think of as the barriers to adoption?

I.e., is the problem or solution really at the HTTP protocol layer?

> Am I missing any other existing HTTP authentication schemes?

Well, there's the one used by the vast majority of web sites:

Initial HTML form POST of plaintext username and password and subsequent 
session cookies (occasionally within required TLS).

It's infinitely customizable by the web site and supported universally 
by browsers and web app frameworks.

If we want to propose something that might be widely used, that's what 
we're up against.

To review, the main problems that might motivate a willingness to change:
* vulnerable to spoofing
* vulnerable to script and cookie origin badness
* doesn't integrate naturally with non-browser clients
* doesn't integrate naturally with federated, single sign on, 
multi-factor, or any other auth schemes
* doesn't have a standard way to log in, log out, change password, 
enroll, etc.
* not necessarily a natural fit for the latest generation of phones and 
tablets which are trending away from keyboard-oriented interaction

Missing any?

- Marsh

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 13:48:34 -0800

> What's the "draft Mutual standard"?

http://www.rcis.aist.go.jp/special/MutualAuth/

Cheers,
tim

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Dec 2010 14:52:45 -0700

> http://www.rcis.aist.go.jp/special/MutualAuth/

Given that this is an IETF discussion list, I think the more appropriate
link is:

http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08

But the more general website provides some helpful background
information, too.

Peter

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

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 14:08:41 -0800

> Other than the recent upward trend towards openid, there didn't seem
> to be much demand for federated auth.

I agree here.  While standardized federated auth is great and would
address a common problem I run across in testing apps (custom SSO
implementations that are almost always badly broken, crypto-wise), I
don't forsee a future where everyone has all of their credentials
stored in the sky.  

Many people won't trust just one site to broker their access, and web
developers won't trust third parties.  I think the most common use
case for multi-site auth is going to be for large organizations with
dozens of public sites, all implemented on different platforms.

Just my opinion.
tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 16:23:59 -0600

On Tue, Dec 14, 2010 at 03:47:55PM -0600, Marsh Ray wrote:
> Another is perhaps browsers are unwilling to authenticate with a
> client cert that they can't validate themselves. Which effectively
> means a browser has to trust the site's custom CA, or the site has
> to get its users into some kind of a commercial arrangement. Not
> very flexible.
> 

Not just.  They're also deployment problems.  If everyone were satisfied
with RP-only, self-signed user certs then the only problem left is that
the user might, for privacy reasons, still want to have different certs
for different RPs.  The moment the user has multiple user certs you get
into credential selection difficulties.

But I don't think it'll be easy to wean anyone from using certs with
meaningful content...  And that's a huge problem because by itself it
leads to multiple user certs.

> to be much demand for federated auth.

I would say that ABFAB WG exists because there is demand for federated
auth.  Same for OAuth and certain SAML profiles.

> As for the ugly browser dialogs, is there anyone other than the
> browser vendors to blame?

They're certainly part of the problem, but browser vendors stopped
improving this situation when everyone stopped using DIGEST-MD5.

> authenticated everywhere they surf. I'm just not going to sign up
> with my drivers license or US passport officially legal credentials
> to leave a comment on some random blog. I'm not necessarily seeking
> anonymity either.

There is that too.  Users *must* have control over when they are
authenticated and _what_ credential is used.

The way I picture it is that there should be an "authenticate" or
"login" button on wbpages, which when clicked, triggers browser chrome
credential selection GUI (note, note necessarily a dialog -- think more
of the way FF tells you that you're offline, for example), with the
user's last choice for this site pre-selected, the user clicks OK and if
necessary enters whatever password/passphrase/PIN might be needed.

> Schemes that expect users to sign up to a central registry are just
> not what people want.

Well, not all the time nor for all services.  With that caveat (which I
think you meant to state anyways) I strongly agree.

> What users seem to want is an easily-remembered password they can
> use all over the place. Hopefully we can get them something better.

Plus something that works when they don't have their password wallet
with them (e.g., when using hotel business center kiosks).

> What most web sites seem to want is an authentication scheme that
> they can customize according to their style and needs and never
> denies access to anyone plausibly legitimate. Often they don't even
> want the user to have to log in more than once, ever. They don't

Modulo session refresh.

> want the user to see another 50ms of latency or bear another 10%
> server CPU overhead for TLS. They want to be able to load Javascript
> from 5 different affiliates and marketing companies.

And they want the whole thing to not cost very much.

HTML form POSTing costs providers very little.  And the marginal cost
for users is also low.  The total cost for users is an unusable system.

> I.e., is the problem or solution really at the HTTP protocol layer?

See my other post today on constraints.

> Initial HTML form POST of plaintext username and password and
> subsequent session cookies (occasionally within required TLS).

That's NOT an HTTP authentication scheme.  That's an application-layer
authentication scheme for applications that a) use HTTP and b) are
browser-based.  I realize that from a user's perspective this
distinction is irrelevant and way too subtle for them to care.  But for
us it should matter a lot.  See my constraints post.

> It's infinitely customizable by the web site and supported
> universally by browsers and web app frameworks.
> 
> If we want to propose something that might be widely used, that's
> what we're up against.

Yes.

> To review, the main problems that might motivate a willingness to change:

Because of weak authentication of servers to users.

> * vulnerable to script and cookie origin badness

I believe these are orthogonal to the problem at hand.

> * doesn't integrate naturally with non-browser clients

Or at all.

> multi-factor, or any other auth schemes

Or at all.

> * doesn't have a standard way to log in, log out, change password,

Yup.

> * not necessarily a natural fit for the latest generation of phones
> and tablets which are trending away from keyboard-oriented
> interaction
> 
> Missing any?

Yes: it's completely unmanageable for users, leading to password re-use
and what not.

Nico
--

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 14:32:47 -0800

Nicolas,

Thanks for the stimulating discussion so far.

> (I consider

I don't.  Trying to dictate APIs in protocol standards is a bad idea, IMHO.

> Cookies do fix that problem...

And introduce a whole host of others.  Once you get a chance to read
the links I sent earlier, we can discuss more.

> just a matter of wording.

Each request is authenticated based on prior state.  If HTTP really is
stateless, then each request is it's own packet which we need to
authenticate.

The distinction I do accept is between cookie session management which
doesn't involve people logging in, and ones that do.  I'd like to see
the latter go away.

> any of SASL, the GSS-API, or EAP?

Right, I understand what you are saying, but I was just trying to
illustrate how even features of a relatively simple protocol aren't
utilized because developers don't take the time to learn them.

If you present people with complex frameworks that include the kitchen
sink, they are likely to use only a fraction of the features of it, if
any at all.  Or worse, if there is a simpler framework out there which
accomplishes just the common use case, it is likely that the complex
framework will just be dropped.

For instance, LDAP servers are very common, but it is very rare for
people to store much more than user identities there.  But directory
servers are capable of so much more.  And isn't LDAP just some small
fraction of X.500 or some such thing?

> build on that to authenticate users and relying parties to each other.

I mentioned my views on federation in message a moment ago to Marsh.

> authentication system (see above).

No, I don't necessarily think SRP the "solution".  On one hand I find
SRP cryptographically "sexy" in what it provides, but I see lots of
hurdles to get over before using it.  

I think the next best step might be to use the tools already at our
disposal to provide a low-implementation cost alternative for web
developers.  Namely, HTTP authentication with forms.  Once HTTP
authentication, with say digest auth, is common place, it isn't hard
for web developers/frameworks to switch seemlessly to more secure HTTP
authentication protocols, provided browsers support it.

As for user certificates, they haven't completely failed.  They merely
languish in obscurity because of weakly defined standards and
implementation complexity.  I think in the long run, due to the O(M*N)
vs O(M+N) difference, client certs really are the closest thing to a
panacea, but they need to be easier to use and implement.
Certificates probably will have to look and behave quite a bit
differently for this to happen though.

tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 16:47:58 -0600

> I don't.  Trying to dictate APIs in protocol standards is a bad idea, IMHO.

I said "abstract" APIs.  There's a reason I believe they matter:
otherwise implementors can miss important application-enabling features.
For example, an HTTP implementor who passes no TLS authentication/
session state up the stack has clearly failed to pay attention, but did
any spec tell them that they should pass that up?  The specific details
of actual APIs are not as interesting.

> stateless, then each request is it's own packet which we need to

Here we start to conflate the sense of "to authenticate".  When we talk
about ESP/AH we say that they can/do authenticate data, but that
authentication ultimately ties back to IKE_SA user<->host or host<->host
authentication in the KE protocol.  Distinguishing authentication of
security entities (such as users and services) from authentication of
data is important, else we'll confuse each other (or at least me).
Cookies are not a strong data authentication method, even when used only
in conjunction with TLS -- the application has no idea as to whether TLS
is providing confidentiality protection, for example (thus no one uses
TLS with only integrity protection).  I wouldn't object to something
stronger, but simply binding application sessions to TLS sessions more
strongly will do.

TLS already provides data authentication.  Sadly there's a break between
"TLS session" and "application session".  And this happens for any
number of reasons, some historical (such as the historical lack of
session resumption without server-side state, and the low rate of
adoption of that now that we have it in the protocol).  There might also
be API issues in some cases (e.g., HTTP not communicating TLS session
information to the application, thus the application being no choice but
to use cookies).

> fraction of X.500 or some such thing?

I don't like your analogy.  I believe you're missing the point about the
need to not force a one-size-fits-all authentication solution on the
market.

> I mentioned my views on federation in message a moment ago to Marsh.

I believe they are quite likely wrong.

> hurdles to get over before using it.  

Sexy, but not really useful for the reason I gave.

> authentication protocols, provided browsers support it.

So how do you propose to take an HTML form POSTed to the server and use
it to key up "more secure HTTP authentication protocols"?  I think
there's a missing link there.

> differently for this to happen though.

See my reply to Marsh on this.

Nico
--

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 15:03:10 -0800

> Sexy, but not really useful for the reason I gave.

"Useful" is pretty subjective, based on your views of what people
actually want.  If it needs federation, then let us add it.
Cryptographically speaking, SRP is sort of the role model for the best
way to provide password-based authentication.

> there's a missing link there.

The missing link is the URLs I sent you earlier.  Please look into it,
because I think there is some real value there.  Once again:

In short:

You can already build an HTML form which submits real HTTP
authentication requests to the site *without* implementing HTTP
authentication in JavaScript.  The XMLHttpRequest API already supports
this.  The API is somewhat generic in the sense that it doesn't need
to be told what HTTP authentication mechanism is being used.  
(Perhaps the API can be improved here.  If so, now is the time to work
with the W3C on that.)

So, if I was a web developer who implemented a web app that used a
form like this and configured my server for Basic auth, I can switch
to Digest auth without any site changes, so long as clients support
Digest. Similarly, I could upgrade to Mutual later.  Multiple
authentication mechansims can be supported at once, though browsers
may need to get smarter about that...

All of this works great while providing non-GUI clients with a way to
authenticate.

tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 16:28:31 -0800

Let me be a little more blunt:  is UI outside the scope of this WG's charter?  I can't find any mention of this WG on the ietf web site.

I'll second the link as being good reading.  I especially liked the comment at the top of page 8:

> Possible Solutions
> The reason digest authentication hasn't caught on has little to do with the security of the protocol. The primary reason is the lack of a flexible user interface. If this barrier to entry could be removed, it should be much easier to convince application developers and administrators of its security virtues.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 18:34:07 -0600

On Tue, Dec 14, 2010 at 04:28:31PM -0800, Henry B. Hotz wrote:
> > The reason digest authentication hasn't caught on has little to do
> > with the security of the protocol. The primary reason is the lack of
> > a flexible user interface. If this barrier to entry could be
> > removed, it should be much easier to convince application developers
> > and administrators of its security virtues.

The same federation issue that applies to SRP applies to DIGEST-MD5 (and
SCRAM).

Without federation users will still end up with N credentials, and
they'll still end up re-using passwords (and usernames) everywhere that
they can.  And never mind that site operators will then be able to
recover the passwords (if they didn't harvest them at account creation
time) from the off-line dictionary attacks on the verifiers.

Users will undoubtedly need to manage N>1 credentials.  However, it'd be
nice if N could be much smaller than dozens.

With federation N<<100 is feasible.

Nico
--

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 16:53:30 -0800

> Let me be a little more blunt:  is UI outside the scope of this WG's charter?  I can't find any mention of this WG on the ietf web site.

Heh, I have no clue, but I would guess it is out of scope.  I just
look at it from a perspective of what pieces need to come together to
provide developers/users what they are accustomed while
improving/replacing the ad hoc security protocols (POST+cookies)
currently in use.

> I'll second the link as being good reading.  I especially liked the comment at the top of page 8:

Thanks.  Note that while I'm all hot on advocating Digest
authentication in the paper, this is just because I'm trying to give
concrete examples of what is available right now that can tangibly
improve the status quo.  However, by moving to one form of HTTP
authentication that is available now, it should be easier to migrate
people to more secure forms of this down the road.

In my view, to set ourselves up for more success, we may want to push
for minor changes to this:
  http://www.w3.org/TR/XMLHttpRequest/#the-send-method

Here, note the text:
 "If authentication fails, Authorization is not in the list of author
  request headers, request username is non-null, and request password
  is non-null, user agents must not prompt the end user for their
  username and password."

So in the XMLHttpRequest object interface, they are allowing
username/password pairs to be specified and thereby triggering the
browser to handle HTTP authentication automatically.  One could also
specify a custom Authorization header from whole cloth, effectively
implementing the HTTP authentication protocol in JavaScript, but I
don't like this idea for a number of reasons.

So, if one wanted to let the browser handle authentication, yet use
more complex auth protocols (ones with federation, or ones in the TLS
layer), then the current API may not be ideal.  I'm not really sure
what other parameters one would need to send in the general case, or
if it should even be addressed here.  

In any case, I think using XMLHttpRequests is the most
straight-forward way to address the problem of: custom GUIs for
people, HTTP headers for everything else.

tim

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 16:56:39 -0800

> The same federation issue that applies to SRP applies to DIGEST-MD5 (and

Don't focus on Digest.  While I disagree that federation can't be done
with Digest (see earlier comments), consider the solution I outlined
for allowing HTTP authentication from HTML forms.  Is the same
technique potentially usable for Negotiate or other HTTP
authentication frameworks that you've worked with?  If not, what would
need to change in the XMLHttpRequest interface to accommodate it?

tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 19:01:09 -0600

> Don't focus on Digest.  While I disagree that federation can't be done

I didn't.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 17:33:08 -0800

> people, HTTP headers for everything else.

IMO the http authentication done for XMLHttpRequest should be same as for normal web page access.  Otherwise we have to solve the problem twice.  Is this not the case?

XMLHttpRequest increases the need to have an authenticated session for performance reasons, but it doesn't have any fundamentally different security needs, does it?

---

From: Tim <[email-masked]>
Date: Tue, 14 Dec 2010 18:21:38 -0800

> IMO the http authentication done for XMLHttpRequest should be same
> as for normal web page access.  Otherwise we have to solve the problem
> twice.  Is this not the case?

Correct, it does in the typical case.  Apparently they allow one to
specify Authorization headers manually in JavaScript as well, which I
think is probably problematic security-wise, but let's ignore that for
a moment.

> XMLHttpRequest increases the need to have an authenticated session
> for performance reasons, but it doesn't have any fundamentally
> different security needs, does it?

No, not different needs, but my proof of concept code (which is really
just stitched together examples from other peoples' pionering work)
is to utilize XMLHttpRequest to accomplish HTTP authentication with
user-friendly HTML forms.  In other words, real, browser-based HTTP
authentication which is initiated through an HTML form but managed
from there on inside the browser's traditional mechanisms.  It
actually works right now, for the most part, with modern browsers, and
will work even better once browsers adhere more closely to the
proposed standard.

In addition, the API in JavaScript is not specific to any particular
HTTP authentication method.  The same exact code works for Basic and
Digest, and probably would work for Mutual.  My concern was that
perhaps it would not work for more complex HTTP authentication
methods.  Right now the API basically accepts just a username and
password.  My question is, should we ask the W3C folks who are
finalizing this standard to allow for other arguments which specify
things that help in federation?  Would it even matter?  I'm not sure. 

tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Dec 2010 18:51:07 -0800

> things that help in federation?  Would it even matter?  I'm not sure. 

Might work for a hypothetical SRP-under-Negotiate method, but probably not for other Negotiate options (depending on eventual browser implementation).

I suspect we should ask for more, but I'd need more study to decide what.  Probably we need more convergence on this list before it's reasonable to know what to ask for.  

There appears to be some preliminary consensus (today anyway) that we need to tie to TLS somehow, so I suspect that's where the extensions would be needed.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 15 Dec 2010 16:08:42 +0900

Hello Tim,

>    http://vsecurity.com/download/tools/fbha-poc_0.1.zip

Is the paper you refer to 
http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html? 
If not, can you send me a pointer?

> However, maybe we should be nudging Anne van Kesteren and her W3C crew

Anne is a he. I have met him personally. I know it's confusing, in 
general "Anne" is female, but he is an exception.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Tim <[email-masked]>
Date: Wed, 15 Dec 2010 08:28:38 -0800

Hi Martin,

> Is the paper you refer to http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html?

That one is a good one to read, but no, my position paper is here: 
  http://vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

You may need to look half way through the paper for the section where
I discuss solutions to the user interface problem.

> general "Anne" is female, but he is an exception.

Oops.  Thanks for the correction.  If you are reading this Anne,
sorry!

tim

---

From: der Mouse <[email-masked]>
Date: Thu, 16 Dec 2010 13:27:37 -0500 (EST)

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

> designer use something other than HTML form POST for the regular

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: Marsh Ray <[email-masked]>
Date: Thu, 16 Dec 2010 13:32:57 -0600

> mistakes to be useful for the purpose.)

Which is a good argument for it being an example of something a computer 
is better at. Many auth systems have a component which involves 
something humans are good at and computers are lousy at.

> corresponding private data....   All passwords demonstrate is
> question knows the password.

That's a good way to describe it.

> But passwords rarely lull people into

Pen-and-paper signatures work because people have thousands of years of 
history behind pen technology. It fits well the courtroom test "did you 
or did you not sign that document". It surely happens, but is extremely 
rare that someone who actually signed a contract would later claim that 
it was a forgery, or that their pen and paper were compromised by an 
attacker.

> attackers poking to see if I've made stupid mistakes.

OK so there's a baseline attack rate for any given port number. If you 
use the system infrequently enough, attackers outweigh the legitimate users.

But, for example, I personally mistype my password about 10 to 25% of 
the time. That's a correct 'authentication denied' scenario but it's not 
an attack. Systems with a meaningful amount of legitimate activity, and 
are not specially targeted for some reason, are going to have many more 
mistyped passwords than credible attacks.

> only once while the other occurs many times.

I bet for a lot of systems, people sign up once and try it out then go 
away and leave their accounts dormant. E.g., I might create an account 
to buy tickets for something and never go back.

So why can't the attacker attack it that one time then?

You've never signed up for a new account from a hotel or a public wifi?

Even still, how do you convince a web designer that they must give up 
their HTML login form for security when they have an HTML login form to 
choose the password in the first place?

- Marsh

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Dec 2010 12:41:43 -0700

> it was a forgery, or that their pen and paper were compromised by an

Perhaps we need a UI that forces you to manually sign (on your tablet
computer) when you send a signed email or securely log in to a website.
That will be popular, no? :)

But I agree that we humans typically understand new technologies or
concepts in terms of old ones.

> choose the password in the first place?

The short answer is that you don't convince them, which is why we've
ended up where we are today.

Peter

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

---

From: der Mouse <[email-masked]>
Date: Thu, 16 Dec 2010 15:02:04 -0500 (EST)

> You've never signed up for a new account from a hotel or a public

I don't think so.  Most certainly not for an account of nontrivial
value (see below) without something at least as strong as ssh securing
the channel from a computer I trust (which is a subset of computers I
own and administer).

>> For all that that's rhetorical, there is an answer: because [initial
>> signup] occurs only once while [login] occurs many times.
> I bet for a lot of systems, people sign up once and try it out then
> go away and leave their accounts dormant.

You quite likely are right.  But in that case the account clearly is of
little value to the holder, so I have trouble getting too worried. :)

> their HTML login form for security when they have an HTML login form
> to choose the password in the first place?

Personally, I don't.  I mostly don't bother with Web stuff at all - you
may note that what I've said here is almost entirely non-Web-specific -
and _never_ do anything involving signups or the like "online"
(meaning, on the Web; I have done such things unsecured over the
Internet, such as creating a login on nethack.alt.org or creating
characters on muds - these are examples of accounts of trivial value).

But if someone were to argue that way with me, I'd basically just shrug
and let it go as "I pointed out the issues; if you want to ignore them
you may be right or you may get burned, and, if the latter, I feel no
responsibility for it".

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Tim <[email-masked]>
Date: Thu, 16 Dec 2010 12:48:49 -0800

> Even still, how do you convince a web designer that they must give
> up their HTML login form for security when they have an HTML login
> form to choose the password in the first place?

This is a good point.  Something that may need to be considered in any
transition plan away from form+cookie auth.  

Should some HTTP Authentication mechanism to sign up for new accounts
and change passwords?

tim

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 16 Dec 2010 10:38:25 -0800

> On the other hand, that's what you have today.  What is it you want for

A picture of a monopoly boot everytime I long into bank of america. Nah
that's what happens today, I'd like something a lot stonger that 50 odd
mostly similar passwords and some inane questions about what school I
went to and what my pet rat's name was.

---

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.

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

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: Marsh Ray <[email-masked]>
Date: Sun, 19 Dec 2010 16:03:52 -0600

On 12/19/2010 03:49 PM, Ben Laurie wrote:
> On 19 December 2010 11:12, Adrien de Croy<[email-masked]>  wrote:
>> Imagine if

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: Adrien de Croy <[email-masked]>
Date: Mon, 20 Dec 2010 11:06:32 +1300

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

only if no-one revoked their certificate.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 20 Dec 2010 09:25:56 +0000

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

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: Ben Laurie <[email-masked]>
Date: Mon, 20 Dec 2010 10:50:09 +0000

> "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 preventin…

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Dec 2010 14:03:39 -0500

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

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.

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.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Dec 2010 15:49:33 -0800

Trimming list to just http-auth.

On Dec 18, 2010, at 8:48 AM, Phillip Hallam-Baker wrote:

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

I don't disagree (much).

I think we agree in principal that the "user experience" is needed in order for anything to succeed.  I also believe that the SAML community has useful input w.r.t. presentation and management of identities at the large scale needed (but that does not negate the need to do it in the browser chrome, not inside a web page).

The problem just got more complex -- or my understanding of it did.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Dec 2010 02:08:38 +0000

> unacceptable (and no, "advertise in the DNS whether to use the DNS" is

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.

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

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

---

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

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

I don't follow. Your example shows an advertisement to service
providers that users fromexample.com <http://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.

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

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.

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.

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.

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.

--
Website:http://hallambaker.com/
_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss