Subject: [http-auth] Proposal: username parameter for HTTP Basic authentication

From: Michael Sweet <[email-masked]>
Date: Tue, 08 Jul 2014 15:21:09 -0400

All,

I'd like to propose a new "username" parameter for the HTTP Basic Update:

    http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01

The purpose of this parameter is to provide the username to be used with a password provided by the user/client.  The use case is authenticated access to an embedded device such as a printer, video camera, router, etc. where separate user accounts may not make sense but where you want to have some form of authentication to prevent casual access to the device.  Currently you have to remember what a given device's chosen username is ("root", "admin", "user", "config", etc.), which makes for a poor user experience.

AirPrint has been using this parameter as an extension to HTTP Basic for several years now...

The text changes are outlined below...

....

Section 2 (The 'Basic' Authentication Scheme), add a new bullet:

    o  the authentication parameter "username" is OPTIONAL (see Section 2.2)

New Section 2.2 (The 'username' auth-param) with the following text:

In challenges, servers can use the "username" authentication parameter to indicate the only supported "userid" value that can be supplied in a subsequent Authorization request header. The value MUST conform to the "userid" ABNF rules.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Jul 2014 00:36:17 +0300

Hi, Michael.

Just to make sure that I understand you correctly, in your use case there are two people (let’s call them “Michael” and “Yoav”) but only one userid, let’s say “prtuser”, There is a single password: “passw0rd” (because we care about security)

So the client sends something like:
Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA== username=“Michael"

So what does the server do with this string? Does it appear in a log? Does the server verify that it belongs to some list of authorized users?  It’s pretty easy to spoof if I know your username and the userid/password combination.  So I’m not sure it counts as “authentication”, although it might be useful.

Yoav

---

From: Michael Sweet <[email-masked]>
Date: Tue, 08 Jul 2014 20:09:32 -0400

Yoav,

> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA== username=“Michael"

No, the client just sends the standard Authorization header as before, with "prtuser:passw0rd" Base64-encoded into the auth string like so:

    Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA==

The challenge from the server for this would look like:

    WWW-Authenticate: Basic realm="My Super Secure Printer",charset="UTF-8",username="prtuser"

> So what does the server do with this string? Does it appear in a log? Does the server verify that it belongs to some list of authorized users?  It’s pretty easy to spoof if I know your username and…

The server is just authenticating as usual, and the "username" in the WWW-Authenticate header tells the client that there is only one possible username/account to authenticate against.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jul 2014 18:54:53 -0700

Certainly nice from a device ui perspective. But also screams attack me using this account cause I'm a router/printer etc. 

What about a username printed on the device? At least the UI problem gets easier and the username is obtained "out-of-band". 

There is also some other approaches being discussed in the ACE WG. 

Phil

> On Jul 8, 2014, at 17:09, Michael Sweet <[email-masked]> wrote:
> 
> Yoav,
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Sophie Bremer <[email-masked]>
Date: Wed, 9 Jul 2014 07:11:50 +0200

I like the idea, because the username is internal and may be unique for device and client - like a special nonce.

For example, you may use username = H( Serial : ClientIP : UserAgent ).

Sophie

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jul 2014 08:22:32 +0200

On 2014-07-08 21:21, Michael Sweet wrote:
> ...

I've got two concerns:

1) If we add this parameter it sort of indicates that new parameters are 
needed in practice, in which case we should make this an extension and 
define a registry.

2) It adds a new parameter with broken internationalization. (We could 
invoke RFC5987 for realm and username, though).

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Jul 2014 09:58:17 -0400

Phil,

> Certainly nice from a device ui perspective. But also screams attack me using this account cause I'm a router/printer etc. 

The Server header in the HTTP response is enough for that.  And nmap and other tools are pretty good at identifying embedded devices on your network already, so I don't think adding this one parameter will make it more likely that the device will be attacked...

> What about a username printed on the device? At least the UI problem gets easier and the username is obtained "out-of-band". 

I don't know about you, but my Wi-Fi access points are in out-of-the-way locations, and such stickers/labels are usually on the back side or bottom of the unit - not exactly convenient (particularly for a printer...) and usually in the dark so it is impossible to read...

> There is also some other approaches being discussed in the ACE WG.

Ah, hadn't noticed that group was formed, however their focus is on constrained devices - IoT stuff - and not on "peripheral" devices like home routers, printers, cameras, etc.  The assumption in that WG is that all constrained devices use RESTful APIs, and many of the current drafts focus on using 3-party auth schemes like OAuth or certificate validation to authorize access to them.  Auto-configuration for that environment will be very important, and it will be interesting to see how they address scaling, discovery, and network boundaries - something that the Homenet and DNSSD WG are working on...

Was there a particular approach you were thinking of that could be used with printers, etc. in place of the "username" parameter?

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Jul 2014 10:29:35 -0400

Sophie,

That's an interesting idea, however since web browsers currently do not support the "username" parameter how would the user discover the correct username to use?

An alternative is for devices to have uniquely-generated usernames (printed on the unit) - that at least avoids the default account backdoor, e.g., username "root", password "root" for a Wi-Fi Router.  That should probably be a recommendation if "username" is adopted.

Neither approach will protect against a brute-force attack, something we should perhaps talk about in the security considerations (for any usage of Basic, not just when "username" is present...)

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Jul 2014 10:41:45 -0400

Julian,

On Jul 9, 2014, at 2:22 AM, Julian Reschke <[email-masked]> wrote:
> ...
> I've got two concerns:
> 
> 1) If we add this parameter it sort of indicates that new parameters are needed in practice, in which case we should make this an extension and define a registry.

Happy to go either way; as an extension we could make specific recommendations about the username value, security considerations, etc. that don't apply to Basic in general.

> 2) It adds a new parameter with broken internationalization. (We could invoke RFC5987 for realm and username, though).

Broken how? We can define "charset" as applying to the username value (and realm, too, for that matter).

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jul 2014 17:12:21 +0200

> Broken how? We can define "charset" as applying to the username value (and realm, too, for that matter).

I wouldn't count on intermediaries and APIs passing through non-ASCII 
octets intact.

Best regards, Julian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Jul 2014 11:14:42 -0400

Julian,

On Jul 9, 2014, at 11:12 AM, Julian Reschke <[email-masked]> wrote:
> I wouldn't count on intermediaries and APIs passing through non-ASCII octets intact.

Oh, right, because HTTP field values are not UTF-8 safe...  I would argue this is more of a problem for realm than the username parameter, but we should say something regardless...

---

From: Phil Hunt <[email-masked]>
Date: Wed, 9 Jul 2014 09:00:05 -0700

See inliine
Phil

@independentid
www.independentid.com
[email-masked]

On Jul 9, 2014, at 6:58 AM, Michael Sweet <[email-masked]> wrote:

> The Server header in the HTTP response is enough for that.  And nmap and other tools are pretty good at identifying embedded devices on your network already, so I don't think adding this one parameter will make it more likely that the device will be attacked…
[PH}Maybe, but randomize the userid helps doesn’t it?
> I don't know about you, but my Wi-Fi access points are in out-of-the-way locations, and such stickers/labels are usually on the back side or bottom of the unit - not exactly convenient (particularly for a printer...) and usually in the dark so it is impossible to read…
[PH] True. But when you first install it, it is visible. I think this speaks to a need for identity memory in the home domain. How do clients remember what identities to use with specific devices, etc. Should there be a repository of identities in the router, in the cloud? Password based auth seems like an anti-pattern even here. May be a token based system...  See ACE comment below...
> Was there a particular approach you were thinking of that could be used with printers, etc. in place of the "username" parameter?

[PH]  The constrained protocol aspects aren’t really an interest in your case. But there’s certainly an IoT aspect of how to register clients and service providers that have limited capability to do sophisticated access or ID management. As in your case, the device only has one basic auth enabled userid and password. 

A token based architecture might be the path to simplicity here. If ACE deals with the IoT registration and discovery issue, then very likely it would work well for home “network” domains.  

The idea here would be to get away from fixed attackable user-ids and allow the home network to depend less on its firewall/NAT security.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 09 Jul 2014 15:02:07 -0400

Phil,

> [PH}Maybe, but randomize the userid helps doesn’t it?

Possibly, but if the other headers provide enough information to identify the device it still really depends on the strength of the password.

The key today is to have a (good) random initial password that is hard to brute-force.  That isn't too hard to incorporate into manufacturing, and more devices are doing this now...

> [PH] True. But when you first install it, it is visible. I think this speaks to a need for identity memory in the home domain. How do clients remember what identities to use with specific devices,…

There are a lot of tricks you can play to authenticate endpoints (chips of various kinds, etc.) to show you are an authorized endpoint, but they doesn't authorize the *user*.  That's why ACE is looking at 3-party auth like OAuth...

> A token based architecture might be the path to simplicity here. If ACE deals with the IoT registration and discovery issue, then very likely it would work well for home “network” domains.  

Agreed, but I think that is at least a couple years away from being put into products, and longer until we can rely on it exclusively...