Subject: [kitten] 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: 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: "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: 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: 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: Yaron Sheffer <[email-masked]>
Date: Sun, 12 Dec 2010 09:29:39 +0200

Hi Luke,

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

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

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

Thanks,
	Yaron

---

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

> SASL does not provide any equivalent method.

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

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

---

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:

> Scanned by Check Point Total Security Gateway.

---

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

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

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 12 Dec 2010 22:36:01 +0100

Why settle for one?

On 12/12/10 7:40 PM, Alexey Melnikov wrote:
> mechanism can be evaluated, people need to agree on a common
> evaluation criteria for HTTP authentication.
>

---

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.

---

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: 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: Dave Cridland <[email-masked]>
Date: Mon, 13 Dec 2010 10:25:52 +0000

> - It has to be integrated in the protocol, not the application

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

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

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

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

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

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

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

---

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

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

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

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: 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: Eliot Lear <[email-masked]>
Date: Mon, 13 Dec 2010 14:46:02 +0100

On 12/13/10 1:14 PM, 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.
> 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: 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: 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:
>
> On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote:
>
>> On Dec 13, 2010, at 12:23, Dave Cridland wrote:
>>
>>> every webapp currently uses a form
>>
>> Yes.  Nice demonstration of conflicting requirements.
>>
> 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 ?
>
>>
>> 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.
>
> Agree.
>
>> 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.
>
> 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.
>
>>
>> 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.
>
> 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"
>
>>
>> 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.
>>
>> websec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/websec
>>
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

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

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

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

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

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

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

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

Here is how I suggest this be achieved:

1) HTTP header

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

Auth-N: domain=example.com

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

2) HTTP Response

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

Auth-N: snonce=<128bits>

3) HTTP Request

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

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

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

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

Conclusion:

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

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

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

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

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

---

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

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

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

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

The organisation then has the opportunity to add value by

a) verifying the true identity of the account holder

b) maintaining reputation information about the account holder

c) revoking abusive accounts.

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

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

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

Regards

Adrien

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) HTTP header

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

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

2) HTTP Response

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

Auth-N: snonce=<128bits>

3) HTTP Request

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

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

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

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

Conclusion:

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

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

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

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

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

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

---

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