Last call for input: Authorization API

[Anton de Winter]

Hi,

http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI

Please have a look at the Auth API doc and see if there are last minute issues you would like to discuss before the API gets put to a vote. In approx. 48 hours I'll be putting the API to a vote (procedure detailed here: http://groups.google.com/group/openrosa-workgroup/web/workgroup-procedures ) if there aren't any major issues.

Cheers!

Anton

[Jonny Heggheim]

Hi!

Sorry for this late reply!

I don't see the need for supporting 3 different ways to authenticate.

Are there some requirements that basic authentication (+ optional
HTTPS) can't meet?


Jonny Heggheim
OpenXdata

On Sep 22, 12:08 am, Anton de Winter <adewin...@dimagi.com> wrote:
> Hi,
>
> http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI
>
> Please have a look at the Auth API doc and see if there are last minute
> issues you would like to discuss before the API gets put to a vote. In
> approx. 48 hours I'll be putting the API to a vote (procedure detailed

> here:http://groups.google.com/group/openrosa-workgroup/web/workgroup-proce...)

[Yaw Anokwa]

hey jonny,

basic auth sends passwords in cleartext. we had an earlier discussion
about this at http://groups.google.com/group/javarosa-developers/browse_thread/thread/d7972bcc4719d9fb

yaw

[Anton de Winter]

Also the newer thread here: http://groups.google.com/group/openrosa-workgroup/browse_thread/thread/be4b5587a70c07f3

Cheers,

Anton

[Mitch Sundt]

Hi Jonny,

The spec defines only one scheme that the device must implement -- a subset of the DigestAuth specification using MD5 hash and a qop of either "omitted" or "auth" (both are required to be implemented).  The differences between these is minor --  the "omitted" variant has security holes that the "auth" variant closed -- and it should generally be avoided.  As far as I'm concerned, "omitted" is in the spec because I don't know what the state of support is for the "auth" variant in all the webserver containers (e.g, Tomcat, Glassfish, Jetty, etc.)

As others have responded, the key problem with BasicAuth is that there are numerous points where wireless eavesdroppers could listen to your data transmissions (e.g., unsecured wireless hotspots, physically non-secure networks).  Since many people lack the knowledge, skill or physical environments to secure their networks, if we support BasicAuth, we should then require all authenticated communications be sent via HTTPS.  That is what we are attempting to avoid by requiring DigestAuth.

Mitch

--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitche...@gmail.com

[Jonny Heggheim]

Hi Yaw!

HTTPS will not send the password as clear text!


Jonny

[Jonny Heggheim]

Hi Mitch!

> As others have responded, the key problem with BasicAuth is that there are numerous points where wireless eavesdroppers could listen to your data transmissions (e.g., unsecured wireless hotspots, physically non-secure networks).  Since many people lack the knowledge, skill or physical environments to secure their networks, if we support BasicAuth, we should then require all authenticated communications be sent via HTTPS.  That is what we are attempting to avoid by requiring DigestAuth.

I totally agree! Maybe my wording should be; HTTPS is required.

Btw, how would you secure the transmissions of the collected data via
DigestAuth?

Jonny

[Brent Atkinson]

Yaw,

Unfortunately digest *requires* that the raw user credentials in order
to build the hash. For projects that are only storing one way hashes,
this requires they subvert all that. I'm not a member of the group so
I can't read the discussion threads, but how does security of the
payload tie into this? That digest scheme isn't much protection these
days, so the trade-off seems a little weak - especially considering
that the payloads are still left unprotected.

Brent

On Sep 22, 4:33 pm, Yaw Anokwa <yano...@gmail.com> wrote:
> hey jonny,
>
> basic auth sends passwords in cleartext. we had an earlier discussion

> about this athttp://groups.google.com/group/javarosa-developers/browse_thread/thre...

[Jonathan Jackson]

Brent - 

Can you clarify why digest requires the raw credentials to be stored?  I was under the impression that they were required to generate the hash once with a known salt.  I did not think you had to constantly keep them in raw form.  I agree if you do, that would be an unacceptable scheme.

Jonny - 

Using HTTPS is definitely recommend (and required depending on your legal environment).  However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.  Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.  

-J

[Jonny Heggheim]

Hi Jonathan!

> Using HTTPS is definitely recommend (and required depending on your legal
> environment).

Sounds great!

>However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.

I thought this API discussion was about authentication (and
transmission of data) and not about storage. Is this off-topic or is
it something we should consider?

> Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.

The above statement is also about storage. But I am curious to know
who stores passwords as plain text?

For example, in OpenXdata all user passwords are stored as SHA1 hash
including a random salt, we never store the password as clear text.

Jonny

[Mitch Sundt]

If you need to secure the data, you would do it over a HTTPS pipe. 

The user's password would be held in memory in the device's application, but not stored anywhere on the phone's sdcard or flash.  I would expect the application to prompt for the user's password each time it is launched.  Note that if you did just Basic Auth, you would still need to hold the password in memory, as each request would send the password, in plain text, over the wire.

While medical applications would require securing the data transmissions with HTTPS, there are a number of other application areas, such as wildlife surveys, where you simply want to ensure that the submitter is authenticated and authorized to submit the form.  That prevents malicious submissions and provides identities of the submitters for survey management.

Other transmissions also don't need HTTPS security in practice, such as:
- getting the list of forms
- downloading form definitions and associated media files (e.g., training videos, images, etc.)
- synchronizing configuration files

For these, it is desirable to know who is requesting the data in order to simplify the choices displayed to a less-trained device user and to do remote phone management (ensuring that user X has the forms and phone configuration they need to do their job).

Generally, these transmissions don't *require* authentication, but do benefit from having the identity of the requester.

Finally, in all these cases, having all requests authenticated mitigates some of the impacts of DoS or other attacks -- it is less burdensome to verify and deny a failed authentication than to blindly set up the streaming of a multi-megabyte video file, and consume resources due to maliciousness.

------------
Mitch

[Simon Kelly]

I think what Brent was saying here is that the raw user credentials are required to verify the hash sent by the client i.e. the server needs access to the raw credentials. This poses a problem for servers like OpenXData, OpenMRS that store passwords as salted hashes. I think this did come up in a previous dicussion but I don't recall it ever being resolved.

--
Simon Kelly
Technical Manager
Cell-Life
Cape Town, South Africa
+27 (0) 21 469 1111
+27 (0) 21 469 1126 (fax)
+27 (0) 72 231 0096 (mobile)
www.cell-life.org

[Brent Atkinson]

Yes,

Simon you understood me correctly. The problem with the digest scheme is that in order to verify that the credentials are valid the server needs to build the same hash. To do that it must know the username, password and realm. This implies that the server must have visibility of the user's password. This is something that many modern software systems spend significant effort to avoid and would require them to take a step backwards security-wise in order to be compliant (if it's required to be compliant).

Jonny: You are correct that you can store the hash, but you'll have to generate and store it for every realm for every user. If you add a realm or change the name and wish to authenticate an existing user, you will require the username and password again to generate and store the new hashes. So, in general, you need the raw credentials on the server if you don't want to require strange work flows on users and administrators.

Brent

--
---
Brent Atkinson
brent.a...@gmail.com

[Mitch Sundt]

Ah.  This is a question I've had about the server side as we try to implement the authentication layers, particularly LDAP (something that we just have prototyped now).  The best description of the process that I have found is at http://docs.moodle.org/en/LDAP_authentication

From this, it sounds like the LDAP system itself can be configured to store the passwords as plaintext, MD5 or SHA-1 hashes.  This would mean that the server would need to communicate in its Auth challenge to the client that it requires either the plaintext password, a MD5 hash of it, or SHA-1 hash to be used when constructing up the DigestAuth hash.  Otherwise the authentication hash cannot be verified.

So perhaps we need an additional header in OpenRosa compliant messages, "X-OpenRosaPasswordTreatment" with a value of "MD-5", "SHA-1" or "plaintext" ?

So that the device knows how to form the hash?

Mitch

[Mitch Sundt]

The question then, too, is -- do any systems do anything more funky than MD5 hashes or SHA-1 hashes of the raw password?  Does anyone add static strings before or after the password before doing the hash?

Mitch

[Clayton Sims]

On Wed, Sep 22, 2010 at 11:17 PM, Brent Atkinson <brent.a...@gmail.com> wrote:

Yaw,

Unfortunately digest *requires* that the raw user credentials in order
to build the hash. For projects that are only storing one way hashes,
this requires they subvert all that.

This point comes up a lot WRT using digest authentication, and it's fully disingenuous. _Every_ form of authentication requires the user credentials on the first run to generate the hash. The only advantage to using some other hash is that many systems already hashes in that format, which shouldn't enter into the argument about what auth scheme is best for our purposes. We should be assuming that systems will be able to request the user re-enter their password, authenticate it against their current one if necessary, and store the new hash for whatever scheme we use.

To be super clear here:

Digest authentication only requires the server to build the user's HA1 hash once, using their username and password (which can be done on the client side, never sending the server the plaintext) the same way making an SHA1 happens per user. 

On Thu, Sep 23, 2010 at 8:58 AM, Brent Atkinson <brent.a...@gmail.com> wrote:

Jonny: You are correct that you can store the hash, but you'll have to generate and store it for every realm for every user. If you add a realm or change the name and wish to authenticate an existing user, you will require the username and password again to generate and store the new hashes. So, in general, you need the raw credentials on the server if you don't want to require strange work flows on users and administrators.

This is a feature, not a drawback of digest authentication. It means that when a user provides their credentials to a server, they are locking the server into not being able to change them, or transport them elsewhere. The point of digest authentication is that the shared secret required by the client and the server is already a one-way function of their credentials and the point of authentication. 

-Clayton 

[Clayton Sims]

Digest authentication supports a header in the WWW-Authenticate request that includes the Hash algorithm that should be used (in practice, if not fully in the specification).

-Clayton

[Brent Atkinson]

Clayton,

Forgive my ignorance, but I don't understand how your response is pertinent. Obviously, credentials are required at first. To my knowledge no one has asserted otherwise. The issue is with whether username and more importantly password are required past that point. Because the HA1 is based on the realm name, you'd have to ask *all* users to re-enter their passwords just to do something simple like change a realm name or adding existing users to a new realm. You can get around this if you keep the username and passwords on the server side. When you change or create new realm names you could then regenerate the hashes. However, if you are storing the usernames and passes like this, storing the hashes has no security benefit, it would just be for performance. Now, if you say you assume a single immutable realm name for any openrosa system, then I agree they are equivalent with other schemes. But then, why is realm included?

Brent

[Jonathan Jackson]

Hi Brent,

I think part of Clayton's point is that saying, "We don't want to go this way because we don't want to rehash the password" is not a good argument against digest because it would be the same if we standardized on SHA1 and you were storing in MD5.  

I believe there were assertions that to practically implement this in a useful way you need to keep the password stored in plain text on the server side, but I don't think that's true based on the previous arguments.

You always need to ask all the users to re-enter their password if you want to update your hashing scheme.  I don' t think that's a fundamental issue.  You can do that lazily and any good back-end architecture should assume you may need to do this to inter operate with other systems.   

Also, even if we do have a global realm, or you only want to support a global realm, it still provides the handshake in an industry standard way.  

-J

[Clayton Sims]

Changing the realm name should require re-acquiring authentication credentials. You shouldn't ever change the realm name unless you're migrating to a fundamentally new service, users provide their credentials for your realm, not for anyone else's, the realm name is the token that lets users know who they're providing credentials to. Taking people's old credentials and adding them to a new realm is basically saying "We've taken your account details and signed you up automagically on our new service, come log in!" which is a violation of user trust.

Agreed that no OpenRosa server should ever store the user's credentials, only the HA1 hash. And I don't think that there should be a single immutable realm, there should be different realms for each deployment. That gives users confidence that their credentials are stored and manged in a limited scope. This is akin to the reason that you need an account on every new Google service, despite them having your credentials: you shouldn't ever sign users up for anything they didn't explicitly provide credentials for, for both security reasons (stealing someone's HA1 hash on ODK aggregate should also give you access to their CommCare HQ account) and for user privacy reasons (The "their credentials, not yours" philosophy).

-Clayton

[Clayton Sims]

So just to clarify a few points about HTTPS+Basic Auth stuff inline:

On Wed, Sep 22, 2010 at 6:19 PM, Jonny Heggheim <heg...@gmail.com> wrote:

> Using HTTPS is definitely recommend (and required depending on your legal
> environment).

Sounds great!

 

Yup, HTTPS should definitely be used wherever possible. (Most servers should require it)

>However, encrypted the payload beyond what https does is arguably not making it any more secure if you are going to store that payload on disk or in a database in an unencrypted format.

I thought this API discussion was about authentication (and
transmission of data) and not about storage. Is this off-topic or is
it something we should consider?

 

Absolutely agree that the Auth API and any device storage should be completely disconnected discussions

 

> Sending the password in plain text over https is less secure because you typically do not store the plain text password anywhere in the system.

The above statement is also about storage. But I am curious to know
who stores passwords as plain text?

For example, in OpenXdata all user passwords are stored as SHA1 hash
including a random salt, we never store the password as clear text.

Storing as an SHA1 hash on the server is a completely legitimate thing to do, and receiving the password in plaintext and hashing it into a hash to compare it is definitely secure in the sense that HTTPS+sending the credentials will not result in the password ever being exposed over the wire. However, there are multiple attacks which make this scheme vulnerable

1) Basic Auth credentials rely on the server that the user is communicating with to be be the correct one, with no verification. If you ever send the wrong server or are in a local network where there is a Man-in-the-middle on the DNS, there is no way to prevent that server from simply replying to any request with a WWW-authenticate response and collecting your plaintext credentials. If a user is on ODK using WIFI, and the router redirects traffic to another computer on the subnet, which gives a 401 response, that computer will _automatically_ get your username and password. This is especially a concern for our users who are in foreign countries where the government has the capacity to manipulate APN endpoints (this has been expressed as a concern by potential users in both China and Zimbabwe).

2) Basic Auth also relies on the server to be uncomprimised at a traffic level. If your server has been compromised at a network level (which is fairly easy compared to a database level), logging the incoming apache (or other server) traffic will give you everyone's user credentials.

3) In Basic Auth, authentication sessions are global and unending (there is no 'login' requiring active input from the user, merely the same token used for every request). The server can't expire local tokens to require re-authentication, meaning that it can have no confidence in the auditability of incoming data records from a HIPAA or other minimum-security-environment regulations.

[Mitch Sundt]

There's the algorithm tag, which specifies the overall hash mechanism (i.e., MD5), but I don't see anything that says whether the A1 value (RFC 2617 section 3.2.2.2 http://www.apps.ietf.org/rfc/rfc2617.html#sec-3 ) used in the construction should be:

A1 = unq(username-value) ":" unq(realm-value) ":" passwd

or

A1' = unq(username-value) ":" unq(realm-value) ":" MD5(passwd)

or

A1'' = unq(username-value) ":" unq(realm-value) ":" SHA-1(passwd)

I think that is where the concern is -- the LDAP systems seem to offer storage of the password as plaintext, SHA-1, or MD5, and if stored as MD5, only a DigestAuth using A' would validate.

Mitch

[Brent Atkinson]

Jonny: I don't think that is an accurate description of the argument I'm presenting.

Clayton: From http://tools.ietf.org/html/rfc2617#section-4.13 it seems that realm is intended for limiting the scope of vulnerability when password files are compromised.

 I didn't raise this up to argue about digest vs. another scheme. I am more concerned that the implementation can be mapped onto common application architectures. It is very common to want to manage user credentials per user (as opposed to the combination user and realm) and membership in a service orthogonally. If this scheme requires significant effort to implement on such systems and you require it for compliance, I'm skeptical it will be adopted.

Brent

[Clayton Sims]

Forgot one more thing

In places where HTTPS is unavailable (for either legal reasons, as in Burma/China etc, or for strange practical reasons like a super strange environment where the client doesn't have a TLS channel capacity), secure authentication shouldn't _also_ become impossible. For a lot of our users, the need for the data to be secure is minimal (The data isn't important), but the ability to audit data being submitted by an authorized user is important. In those environments, the HTTPS negotiation overhead is rough due to super-low throughput rates on the GPRS channel (Overall communcation bandwidth is low, but it's a chatty negotiation process), so being able to send plaintext submissions with authorized credentials is a nice thing to have.

-Clayton

[Mitch Sundt]

From section 3.2.1 of RFC2617:

 realm
     A string to be displayed to users so they know which username and
     password to use. This string should contain at least the name of
     the host performing the authentication and might additionally
     indicate the collection of users who might have access. An example
     might be "register...@gotham.news.com".

Section 4.x of the spec outline security concerns with the authentication mechanism, and don't imply any required implementation.  The point of that section is that a file containing all data for a given realm would compromise access to that realm.  That the A1 hash includes the realm as part of the hash, so it limits the compromise to just that realm.

Mitch

[Clayton Sims]

On Thu, Sep 23, 2010 at 2:28 PM, Brent Atkinson <brent.a...@gmail.com> wrote:

Clayton: From http://tools.ietf.org/html/rfc2617#section-4.13 it seems that realm is intended for limiting the scope of vulnerability when password files are compromised.

Right, if a user provides their credentials to your realm they shouldn't also be providing their credentials universally. Realm is intended to provide a scope of authentication for both the users and the server so that adversaries who gain access to one don't gain access to all of them.

 I didn't raise this up to argue about digest vs. another scheme. I am more concerned that the implementation can be mapped onto common application architectures.

Digest authentication is readily available on ~all server environments, and JavaRosa contains an implementation for J2ME clients which took about a day to write (it is extraordinarily rare for a platform to not support digest auth with a simple library, j2me is very much the exception). 

It is very common to want to manage user credentials per user (as opposed to the combination user and realm) and membership in a service orthogonally. If this scheme requires significant effort to implement on such systems and you require it for compliance, I'm skeptical it will be adopted.

Implementing digest authentication simply requires servers to be capable of requesting users to enter their password again (once for the initial login, and once anytime the realm is compromised and the server needs to generate new credentials). In the steady state, this requires only one password entry phase, which I'm unconvinced is onerous for developers. It requires developers to manage user credentials more carefully and in a more limited way (per 'realm'), but this mostly just means that you can't move users between servers that don't share a realm.

Also, compliance in an Auth standard also means that we should be comfortable directing our users to use other systems interoperably. I'd be uncomfortable directing our users to use any of the secure tools to communicate with a server which didn't implement authentication at a level which provided the benefits that digest auth does. Especially if convenience of moving user credentials around between servers was the reason, since that introduces inherent security problems. 

[Brent Atkinson]

Clayton,

Assuming an application only exposes a single realm, the hashes can be managed similarly to existing schemes. This doesn't bother me so much anymore. I'm aware that digest isn't difficult to implement from a technology standpoint, but that wasn't a concern. Dictating a particular user management system is a little heavy handed and uncommon for interop specs (in my experience). But, in the interest of moving things along I am willing to concede and will retreat back into my cave.

Thanks for sticking with me on this,

Brent

[Jonny Heggheim]

Hi Clayton!

> Digest authentication is readily available on ~all server environments, and
> JavaRosa contains an implementation for J2ME clients which took about a day
> to write (it is extraordinarily rare for a platform to not support digest
> auth with a simple library, j2me is very much the exception).

Supporting digest on the OpenXdata server would force us to make major changes.
I don't know what changes OpenMRS, DHIS and different LDAP servers
etc. are forced to do if they choose to adopt the current OpenRosa
Authentication API.

My main concern is that we will get less OpenRosa compliant servers
(and maybe clients) if we push this API though.

Jonny

[Jonny Heggheim]

Hi Clayton!

> Digest authentication is readily available on ~all server environments, and
> JavaRosa contains an implementation for J2ME clients which took about a day
> to write (it is extraordinarily rare for a platform to not support digest
> auth with a simple library, j2me is very much the exception).

Supporting digest on the OpenXdata server would pose a big impact.
I don't know about what impact OpenMRS, DHIS and different LDAP
servers etc. would implement this on their servers.

My main concern is that we will get less OpenRosa compliant clients
and servers if we force them to make big changes in their system.
OpenRosa 1.0 more advanced than needed.

Jonny

[Jonny Heggheim]

Please ignore this last post, it was just a draft.


Jonny

[Clayton Sims]

Jonny,

Can you elaborate on the concrete difficulties that would be faced to get OpenXData capable of utilizing digest authentication? Given how simple it was to get digest auth working on j2me with ~no support from the environment, I feel like it should be possible pretty easily to support digest auth on a normal Java based server. 

I'm sure the community could provide resources to overcome any difficulties that would be faced in different server environments if groups think they would pose a particular burden for implementing them on their system. Especially since we eventually want to standardize of the methods by which user credentials are registered and managed if possible

-Clayton

[Clayton Sims]

Brent,

You're absolutely right that we should try to avoid over specifying or over-reaching the intent of each of the API's. I agree that we shouldn't be directly dictating things like what a user is, or how their model/credential is stored, manipulated, or managed in particular. It's definitely something we should be careful to not include directly in the API. If a group of tools want to use a single realm to simplify user registration or management between systems, that should absolutely be supported using the OpenRosa standard. I just don't want to lose the medium-strength security capabilities that we get from digest auth in order to encourage that kind of user management on the back-end.

And I apologize if my approach came off somewhat aggressive on those points. I came into this discussion from the perspective that there was a notion (stated to me by others as a result of conversations) that digest auth was less secure because one "needed" to store plaintext values (to be able to dynamically build A1 hashes), which I wanted to make sure wasn't a factor for anyone's approval of the API (since the debate should be focussed on user portability in that case, not security). I hope I didn't come off as dismissive of the notion overall that other Auth schemes had merits worth balancing and debating.

-Clayton

[Brent Atkinson]

Clayton,

No problem, I like heated debates as long as they converge to meaningful conclusions.

:D

[Mitch Sundt]

Can anyone comment on this?  I think this might be a core issue in backend LDAP integration.

[Jonny Heggheim]

Hi again, I just arrived back in Norway.

Minor issues for OpenXdata server:
* Maintaining an extra authentication scheme.

Major "specification lock-in" problems:
Digest dictate how we store users passwords and that makes it harder
to share login with other 3rd party systems.
* What LDAP servers support or will support the OpenRosa Authentication API?
* What if OpenXdata users are stored in another appliaction (ex;
OpenMRS or DHIS)?

in contrast, OpenRosa with basic authentication would just be another
view/client on top of OpenXdata server.

Jonny

[Jo Størset]

Hi,

I'm not really affiliated with openROSA, as of now, and I've only briefly read through the discussions, but thought I'd share some thoughts from a DHIS perspective (or maybe more accurately from my own perspective, working on dhis and mobile :).

Johnny wrote:

> Major "specification lock-in" problems:
> Digest dictate how we store users passwords and that makes it harder
> to share login with other 3rd party systems.
> * What LDAP servers support or will support the OpenRosa Authentication API?
> * What if OpenXdata users are stored in another appliaction (ex;
> OpenMRS or DHIS)?

As http digest incorporates the *web* server realm, it is not practically possible to use any form of centralized user management (LDAP/AD) on the server side with this mechanism. You will quickly be forced to have a separate user db for the single app (if security policies allow you), giving better "technical" security than with basic, but at the cost of worse security at a higher level (and you'll find that in "enterprise" environments you might have to follow their security policies rather than a spec like this).

On the other hand, I'm not convinced that a little security over the wire really is that much better than not hashing the passwords on the server side (which digest effectively makes impossible - you can have a static realm and store the user:realm:pass hash, but then what you store is effectively the secret needed to log in to the server with digest, anyway).

The only way to really move further with security is to implement third-party authentication mechanisms (OAuth, SAML), and in time effort could probably be put into that also for mobile clients (and maybe by allowing some kind of way to additionally allow better auth mechanisms in the spec?).

But for now, I really don't see the point in ruling out basic auth. It is really easy for a client to support basic if it already supports digest, it is not necessarily possible for a server to support digest. I think a spec like this should maximize interoperability, not so much force security on implementations.

At least, I am pretty sure I won't be able to make existing implementations of DHIS reinitialize all their users, even if I could convince the developers of changing the auth mechanisms. And I certainly won't be able to make big organizations change their infrastructure and policies to follow this spec (read centralized user db). So I think from a dhis point of view, we would have to choose to be non-compliant, as it is now.

My 2 paisa (hope I don't step on anyones toes :)
Jo

[Jonathan Jackson]

Hi Jo,

Thanks for the good feedback, its a helpful perspective.  I think we may want to implement more standards in the future such as OAuth or SAML, and agree a registry based user id scheme is ideal, but I don't know that the mobile teams have the time to do so now.  My argument against basic auth, which could be flawed, is that its difficult to make HIPAA compliant so likely a non-starter for any project seeking to work in the US.  Many hardened server deployments log every web access, the web log would contain exposed user passwords.  How do you get around this today on DHIS if you allow basic auth?  

Also, you can implement this transparently if you are allow users to valid in plain text today, because you can create the hash on the fly for users over some period of days (say 90).  And, if they didn't sign on during that period, you would have to request they input the password twice in a row, one time (which they are going to have to do anyways since they almost definitely forgot the password if they haven't logged in for 3 months).  

So, this is not saying OpenRosa won't support OAuth or SAML in the future, but that we are trying to make an incremental step in the right direction.  All that said, I do think that some servers may not choose to not to implement OpenRosa compliant specs for a variety of reasons; if I may inquire further, are you saying that DHIS would try to become OpenRosa 1.0 if Basic was an available option (including implementing the 5 other APIs as well) but not if Digest is required?  

Cheers,

Jonathan 

[Jo Størset]

Den 28. sep. 2010 kl. 18.15 skrev Jonathan Jackson:

> Thanks for the good feedback, its a helpful perspective. I think we may want to implement more standards in the future such as OAuth or SAML, and agree a registry based user id scheme is ideal, but I don't know that the mobile teams have the time to do so now. My argument against basic auth, which could be flawed, is that its difficult to make HIPAA compliant so likely a non-starter for any project seeking to work in the US. Many hardened server deployments log every web access, the web log would contain exposed user passwords. How do you get around this today on DHIS if you allow basic auth?

We don't really have that kind of deployment, so it would be kind of hypothetical. I don't know anything about HIPAA, either, but I guess the obvious answer is third party authentication :)

> Also, you can implement this transparently if you are allow users to valid in plain text today, because you can create the hash on the fly for users over some period of days (say 90). And, if they didn't sign on during that period, you would have to request they input the password twice in a row, one time (which they are going to have to do anyways since they almost definitely forgot the password if they haven't logged in for 3 months).

Yes, good point, that would be possible for existing implementations. It wouldn't change the problems with central user management (or that the stored key would be the secret needed for authentication).

> So, this is not saying OpenRosa won't support OAuth or SAML in the future, but that we are trying to make an incremental step in the right direction.

Fair enough, I just think that choosing digest can make migration/coexistence with these other solutions more difficult.

> All that said, I do think that some servers may not choose to not to implement OpenRosa compliant specs for a variety of reasons; if I may inquire further, are you saying that DHIS would try to become OpenRosa 1.0 if Basic was an available option (including implementing the 5 other APIs as well) but not if Digest is required?

I must admit that I haven't really thought about it much and don't know if other DHIS people have. I'm kinda new to the mobile side of things, so haven't looked too closely at the openROSA specs either. We will focus a lot more on mobile clients in the time ahead, though, and I would hope we can collaborate and avoid reinventing wheels as much as possible. But I think we still are at a stage where we need to move fast and have to focus on getting implementations deployed, first. We're also very much focussed on resource-constrained settings, so I'm not sure if the fit is all that great (?)

All in all, I wouldn't bet on us having capacity to implement something like this just yet :) Will try to bring it up for discussion, though.

Anyway, I just thought maybe letting the server decide between basic auth (over ssl), digest or both, wouldn't be a huge dent in the spec, and shouldn't add much complexity to clients (since basic after all is much simpler than digest). But I'll leave the decision to you guys :)

Jo

[Jørn Ivar Klungsøyr]

Hi,

Great with heated discussions...

Wondering about the more general issues.

Is it so that a solution only is OpenROSA compliant if it has implemented all OpenROSA standards?

I would say no to that.

Rather, any solution should state which OpenROSA standards a solution is compliant with.

So that in a list of standards a solution follows one would find: E.g.

OpenROSA xForms 1.0
OpenROSA Authorization 1.0
OpenROSA Statistics 1.1

Alternatively that if all standards are implemented (of a specific version )
OpenROSA Standards 1.0 (which then would be specific versions of the different standards).

This way groups can decide what standards to implement and not - and over time more and more solutions will have more or less compliancy levels.

Best regards,
Jørn
____________________________________________________________________________
Jorn Klungsoyr
openXdata - Centre for International Health, University of Bergen, Norway
www.openxdata.org / www.cih.uib.no / www.openrosa.org / www.open-mobile.org
Mobile: +4791365731, Office: +4755588574, Skype/GoogleTalk: jornklung Alternative email: jorn.kl...@gmail.com
Post: Postboks 7800, 5020 Bergen, Visit: Årstadveien 21, 5th Floor, Bergen
------¤¤¤¤------

[Jonathan Jackson]

Hi Jorn,

I agree we do want to have profiles.  However, we had agreed at the OpenRosa conference to have a minimum set of standards for each profile.  The default profile is basically trying to get an arbitrary mobile client (JR / ODK / OXD) to be able to submit to an arbitrary backend (HQ / OXD / Aggregate).  We need auth for that to work, but not statistics.  

-J

[kieran sharpey - schafer]

Hi Jon & Jorn,

Yes thats right, I do remember the 'profiles of compliance', but I don't think we got it down here:
http://wiki.openmrs.org/display/RES/OpenRosa+2010+Discussions

perhaps currently we have two:
submission profile (minimal Jon mentioned)
full profile

and perhaps patient profile? or maybe thats just openMRS? would commcare and openMRS-jr have the same profile?

All the best,
Kieran

--
----------------------------------------------
Kieran Sharpey-Schafer

mobile: +27 72 371 6469 (SA)
mobile: +1 347 703 9280 (US)
skypeid: kieran.sharpey.schafer

[Clayton Sims]

We haven't really described a Patient Profile too well. I'm not super convinced it's a generic enough setup to be a "Profile" as opposed to a specific setup for a JR app.

I can imagine three profiles which build on each other and comprise the main standards set.

Data Profile (No authentication or users, just download XForms onto phone and submit data back to server).

 - Server: Form Receiver, Form List

 - Phone: Form Downloader, Submission

Secure Profile (Same as minimal, but with users, authentication, etc)

 - Server: User Registration, Authentication

 - Phone: User Registration, User Login, Authentication

Two-Way Profile 

 - Server: Data Model Generator

 - Phone: Data Model Downloader

Along with other optional profiles (Statistics, Multimedia, etc) being included on top

-Clayton

[Munaf Sheikh]

If Patient profile isn't generic enough, why not replace it with something more generic, which incorporates patients and/or other entities that have similar functionality to Patients. Can there be a profile for downloading "Entities" and "Parsing them", maybe creating new ones or submitting  ??

Also, what is a "data model downloader"

-----------------------------------------------------------------
Munaf Sheikh
(Cell-Life)

"Change your thoughts and the world around you changes."

[Clayton Sims]

Given our close relationship with OpenMRS a patient profile might be worth exploring, but I'm definitely down with integrating more generic functionality into the package.

The entity profile is definitely worth thinking about (That's very similar to what we do for commcare). 

The data model downloader is what we talked about at the meeting as being the first-step for patient/entity stuff. Basically you have Forms (A,B,C) on your device, and the server (Based on your username, or some metric) sends you instances for those forms (A_1, A_2_, A_3, B_1, etc) which are pre-filled with much of the data (names, concept #'s, etc). You search for those models based on simple string checks, (generally patient names or ID's, but could be anything), and finish filling out that model, using the pre-filled data, then send it back to the server.

This would give servers a _lot_ of flexibility for what kind of data they can download to the phone (Arbitrarily complex XML models are pretty important for things like OpenMRS) and doesn't require the phone to expect any structured "entities", just whatever could be in the forms downloaded from the server.

-Clayton

[Mitch Sundt]

I've been referring to partially-filled-in forms like this as "follow-ups".

I'm definitely interested in defining something like a Follow-Up profile.

Entity implies an name-able individual, but a follow-up might be something as generic as "go to this location and survey what you see within 100m of it".  A form like that lacks an entity.

Mitch

[Yaw Anokwa]

the location you are going to could be that entity's id. that is, you
are filling out a form about *something*.

[Mitch Sundt]

Yes, that is a way to force the concept of a Follow-Up to fit into an Entity model.  I don't think they have to.  Follow-ups are the more general construction. 

I should note also that submissions can describe multiple Entities and the relationships among them (familial, proximal, co-temporal, etc.).  Only in the medical setting is there necessarily a dominant Entity (patient) associated with the submission.

Mitch

[Samson Gejibo]

Hi,

I want to throw my thought on this hot discussion. I haven't thought of authentication_API or security in general will be a barrier for services integration. On the proposal, I can see implementation challenge on the system like OpenXdata. I am just wondering why don't we follow standard like SAML or TLS/HTTP. I believe sooner or later we need more security mechanisms for data. 

This proposal seems a challenge-response, one-way authentication based on digest and can be two-way authentication if the client able to authenticate the server using cnounce (which is not included in proposal) (please correct me if I am wrong). Hence, it is relied on one way authentication, which is similar with basic authentication ( If we transmit credentials in secure way). TLS/SSL and  XML security (SAML) are potential solution for our need. Features extensibility (confidentiality, Integrity and sender or receiver authenticity....) and Interoperability are the key benefit from these standards.

 

I need know the motivation behind implementing OpenRosa authentication API than following standards. How do you describe the performance issues on the mobile devices (jar size increment, computation, authentication time...). How do you compare it with TLS/SSL or SAML? 

 

Hashing password and storing with its salt value is the modern of way securing password, the proposal don't support this instead it require plain text password. In this case we need another implementation to secure plain text password.

 

 

With Great appriciation.

 

__________________________________________________

Samson Gejibo

 

Centre for International Health (CIH)

University of Bergen (UiB)

Bergen, Norway

Mob: +4798123374

 

 

On Wed, Sep 22, 2010 at 12:08 AM, Anton de Winter <adew...@dimagi.com> wrote:

Hi,

http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI

Please have a look at the Auth API doc and see if there are last minute issues you would like to discuss before the API gets put to a vote. In approx. 48 hours I'll be putting the API to a vote (procedure detailed here: http://groups.google.com/group/openrosa-workgroup/web/workgroup-procedures ) if there aren't any major issues.

Cheers!

Anton

--

[Mitch Sundt]

Hi Samson,

One concern with OpenID or SAML is that it has a number of redirects and is rather chatty.  See the communications diagram in http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language   If you're working over a low-data-rate connection, or if the identity provider is not co-located with the server you are accessing and there are network connectivity issues, this could be an issue.  Keep in mind that smaller communities in Africa are a key region we want to support with the OpenRosa standards.  Those communities may have lower-reliability networks and intermittent or non-existent non-local connectivity.  For cellular phone communications, there is also the increased expense if you are paying for bandwidth to your phone.

To re-iterate -- the OpenRosa authentication standard *is* following an IETF standard -- RFC 2617 -- but where OpenRosa spells out additional minimal implementation requirements so that every *minimal implementation* will overlap in a well defined subset of that larger standard -- so that minimal implementations can be guaranteed to inter-operate.

• I do think there are valid issues with how Digest Auth integrates and plays with LDAP or other authentication infrastructures.

• I don't think security improves by sending plaintext passwords (Basic Auth) over a TLS/HTTPS pipe, through the server, and to the authentication infrastructure.  These servers may not be physically secured, they likely won't have security-aware people running them, and there is always the risk of logging functions within the server inadvertently recording credentials.
  

• I don't think every communication to and from the phone should be required to be sent through a TLS/HTTPS pipe -- something that using Basic Auth over TLS/HTTPS would require.

RFC 2617 doesn't provide a way to authenticate the server short of verifying the digest value of the entire response.  The OpenRosa authentication standard doesn't preclude the server sending this response digest and it doesn't preclude the device verifying this if it is present.  It isn't in the minimal implementation because that would require it be sent on every response and that the device verify its value when processing each response.  The minimal implementation must support a qop of "auth", which would utilize a cnonce on the device.  The cnonce itself is not intrinsic to server authentication, just like a response digest value isn't, but they both are a prerequisite for server authentication only because of the way RFC 2617 was structured.

-----------
As Clayton has already pointed out, with DigestAuth (RFC 2617), the plaintext password does not need to be stored or known on the server -- what is required is the ability for the server to determine the MD5 hash:

MD5( username ":" realm ":" passwd )

The availability of this hash (where the passwd salt is a prefix of "username:realm:") is equivalent to the availability of the hash from the "modern way of securing passwords."  It just specifies a specific salt and hash function.

This hash is the A1 value in RFC 2617.  Everything else in that specification is there to provide changing salts on the wire from the server and client side so that eavesdroppers cannot guess this fixed hash by looking at the values flowing over the airwaves/wire.

Hope that helps.

Mitch

[Jo Størset]

Den 3. okt. 2010 kl. 12:02 skrev Mitch Sundt <msu...@cs.washington.edu>:

> As Clayton has already pointed out, with DigestAuth (RFC 2617), the plaintext password does not need to be stored or known on the server -- what is required is the ability for the server to determine the MD5 hash:
>
> MD5( username ":" realm ":" passwd )
>
> The availability of this hash (where the passwd salt is a prefix of "username:realm:") is equivalent to the availability of the hash from the "modern way of securing passwords." It just specifies a specific salt and hash function.
>
> This hash is the A1 value in RFC 2617.

Actually A1 *is* the secret needed to login to the server, and storing this *is* equivalent to storing the plaintext password when digest auth is offered.

Otherwise I agree :)

Jo

[Clayton Sims]

Yeah, I agree that Entity is the wrong name (it also implies you are able to do concrete things, in my opinion, which you likely can't), although I'm not sure Follow-Up is quite there either. Names aside (I think we can make an executive decision what to call it once we've spec'd it out), it seems like we agree that it's an important need. 

Maybe we should set up a skype talk some time this week to finalize a draft of this workflow? From download to search (if any) to resubmission? As usual, I think having a draft to start from would be best. I'm willing to do that if no one else feels particularly compelled.

-Clayton

[Mitch Sundt]

I hope to shortly have code showing an OpenLDAP integration for digest auth (and its rough edges) to help inform this discussion.

Mitch

[Yaw Anokwa]

maybe the us-based folks can hack out a draft and we can iterate from
there? i'm free most of wed morning seattle time. clayton you make it?
mitch?

[Mitch Sundt]

OK.  Here is the relevant part of the code required to implement DigestAuth using OpenLDAP.  Note that the LDAP system will return the USER_PASSWORD to the application, which can then construct the A1 value, construct the over-the-wire hash of that, and test for equality to complete the authentication.  The server isn't storing the A1 value, a plaintext value, or anything -- all the information is coming from LDAP.

The ONLY issue with this process is that the value for USER_PASSWORD that is stored in an LDAP system is now often following RFC 2307 (experimental).  The LDAP standard (RFC 2256) states that this is the plaintext password, but RFC 2307 (experimental) returns hashed or salted-and-hashed passwords identified by a scheme.  e.g.,:

{sha}HashedPassword

or

{ssha}saltedThenHashedPasswordSalt

Where the salt is appended in plaintext to the salted-and-hashed password.  The salt is different for each password and is intended to prevent dictionary attacks across all userids registered in an LDAP server should a malicious program gain access to the LDAP service.

This is a good link for background: http://www.openldap.org/faq/data/cache/347.html  This is a good description of salted hashes: http://www.owasp.org/images/3/33/Salted_Hashes_Demystified.doc

This is a page from OpenLDAP security manual: http://www.openldap.org/doc/admin24/security.html  Scroll down to section 14.4  Note this: "The disadvantages of hashed storage is that they are non-standard, may cause interoperability problem, and generally preclude the use of stronger than Simple (or SASL/PLAIN) password-based authentication mechanisms such as DIGEST-MD5."

For unsalted hashes, if the hash function in the curly braces is communicated to the client as part of the auth challenge, then the client can compute the hash of the entered user password first, then construct the suitable A1, and the verification proceeds.  Note that this is exactly what the snippit.java would be doing on the server if the plaintext password were sent from the client via BasicAuth.  It would have a if-else branching to do the suitable hash code on the plaintext before comparing it to the value returned by the LDAP server.

For salted hashes, the hash function in the curly braces and the salt need to be communicated to the client. Since this salt is per-user, there isn't a security compromise by sending this in plaintext to the client, as it is intended to prevent dictionary attacks against all userids in the LDAP server should any program gain access to the LDAP service, and if any program did gain access to the LDAP service, this salt is directly available already.  It is much like the nonce and cnonce values being passed as plaintext.

I'm still researching what you'd need to do with a framework such as Spring to get it to supply these values to the client device.

Mitch

[Mitch Sundt]

Works for me.

[Clayton Sims]

I think that works for me.

-Clayton

[Yaw Anokwa]

alright. let's aim for 9am pdt (noon edt). if anyone wants to
participate, show up to the skype chatroom at http://goo.gl/wcFY. i'll
have a conference room setup so we can discuss over voice.

[Samson Gejibo]

Hi Mitch,
 
 

On Sun, Oct 3, 2010 at 8:32 AM, Mitch Sundt <msu...@cs.washington.edu> wrote:

Hi Samson,

One concern with OpenID or SAML is that it has a number of redirects and is rather chatty.  See the communications diagram in http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language   If you're working over a low-data-rate connection, or if the identity provider is not co-located with the server you are accessing and there are network connectivity issues, this could be an issue.  Keep in mind that smaller communities in Africa are a key region we want to support with the OpenRosa standards.  Those communities may have lower-reliability networks and intermittent or non-existent non-local connectivity.  For cellular phone communications, there is also the increased expense if you are paying for bandwidth to your phone.

 

If we plan to implement SAML, due to infrastructure limitation, the identity and service provider should be located on the same place/same machine.

I strongly agree on data-rate problem in a place like Africa, but we still have GPRS coverage, I do think it is enough for client - server authtication. At the time of authetication there might be reseaonable delay.

 

To re-iterate -- the OpenRosa authentication standard *is* following an IETF standard -- RFC 2617 -- but where OpenRosa spells out additional minimal implementation requirements so that every *minimal implementation* will overlap in a well defined subset of that larger standard -- so that minimal implementations can be guaranteed to inter-operate.

• I do think there are valid issues with how Digest Auth integrates and plays with LDAP or other authentication infrastructures.

• I don't think security improves by sending plaintext passwords (Basic Auth) over a TLS/HTTPS pipe, through the server, and to the authentication infrastructure.  These servers may not be physically secured, they likely won't have security-aware people running them, and there is always the risk of logging functions within the server inadvertently recording credentials.
  

          I do agree with the concern of recording credentials but this also has advantage for security audit. I think what we need is to secure those audit/log file.  

 

• I don't think every communication to and from the phone should be required to be sent through a TLS/HTTPS pipe -- something that using Basic Auth over TLS/HTTPS would require.

   We don't need secure tunnel for entire communcation unless otherwise we need it. Instead, we use it only for secure authtication. After authtication completed,  we can drop the secure tunnel. 

 

   As we secure user credintials, we also need to secure user data. In that case, Secure tunnel will be utlized.

 

 

Here, I do have an argument on the improtance of two way authentication. In our senario, the client need to be authticated on two events: when form dowbloaded and data uploaded. Identifiying Genuine/Trusted data submitter and Identifying Genuine Server (server who receive data from the client) are the major challenges to be addressed at the authetication level. I think the value of identifying genuine server is more weigh than identifying submitter. OpenRosa_Auth is for authenticating data submitter. How do we make sure the client is uploading data to genuine server? 

 

Basic authtication over TLS/HTTP can address both issues. The server authenticates client using username/password and client autheticates server using server certificate. The cost of certificate might be an issue but self-signed or free certifcates from CA (http://www.cacert.org/can) can be a solution.

   

 

 

RFC 2617 doesn't provide a way to authenticate the server short of verifying the digest value of the entire response.  The OpenRosa authentication standard doesn't preclude the server sending this response digest and it doesn't preclude the device verifying this if it is present.  It isn't in the minimal implementation because that would require it be sent on every response and that the device verify its value when processing each response.  The minimal implementation must support a qop of "auth", which would utilize a cnonce on the device.  The cnonce itself is not intrinsic to server authentication, just like a response digest value isn't, but they both are a prerequisite for server authentication only because of the way RFC 2617 was structured.

-----------
As Clayton has already pointed out, with DigestAuth (RFC 2617), the plaintext password does not need to be stored or known on the server -- what is required is the ability for the server to determine the MD5 hash:

MD5( username ":" realm ":" passwd )

The availability of this hash (where the passwd salt is a prefix of "username:realm:") is equivalent to the availability of the hash from the "modern way of securing passwords."  It just specifies a specific salt and hash function.

This hash is the A1 value in RFC 2617.  Everything else in that specification is there to provide changing salts on the wire from the server and client side so that eavesdroppers cannot guess this fixed hash by looking at the values flowing over the airwaves/wire.

Hope that helps.

Mitch

 

Apart from solving authtications problem, is there a progress to secure data on the communction channel? or is there any security issues we can put effort together? If we work together for a common goal,  "Secure mHealth system---Data capturing system", I believe we can produce inter-operable solution.  

 

  

With all appreciation.

 

--Samson

--

[Mitch Sundt]

If the authentication is done in plaintext in a one-time https pipe:

1) what is the impact of this on a smart phone cpu, low bandwidth connection -- the setup of the pipe would incur a 6k - 10k overhead for session establishment.

2) are there impacts w.r.t. any regulatory (HIPAA) or other privacy regulations?

If we do this, then is there a standard for session cookies (presumably conveying the identity of the client and server in a cross-platform, secure, way) that we would be adhering to?  I'm not up on the possible HTTP protocol choices or RFCs.

Mitch

[Yaw Anokwa]

just a reminder that those who want to discuss this should be in the
javarosa chat room at http://goo.gl/wcFY. we'll start at 9.05, so you
have 10 minutes.

[Yaw Anokwa]

we've had a productive meeting. i've typed up a high level overview of
what this functionality would look like at
http://bitbucket.org/javarosa/javarosa/wiki/HistoricalFormDownloadAPI.
turns out it is pretty straight forward.

mitch and clayton will start spelling out the technical details, but
now is the time to start offering your feedback!

[Jonathan Jackson]

1) what is the impact of this on a smart phone cpu, low bandwidth connection -- the setup of the pipe would incur a 6k - 10k overhead for session establishment.

2) are there impacts w.r.t. any regulatory (HIPAA) or other privacy regulations?

 

If we are concerned about HIPAA regulations, you basically must use https for all data communication involving protected health information (PHI).  In addition, passwords are not allowed to be stored in plain text so basic auth will not work for HIPAA compliant servers.  Even if its hashed in the application database, server logs or intrusion detection logs would still have access to the plain text logs given sys-admins the login information for any user.  

Note that if you are going through Institutional Review Boards (IRB) at Academic Institutions in the US or Europe (and increasingly Africa) for survey data and you are collecting PHI, you will most likely be subject to HIPAA regulations (and Europe is even more strict than the US HIPAA laws).  

-J

[Clayton Sims]

Yaw,

Thanks for this first draft, I'll get rolling on some of the technical details ASAP.

-Clayton