Open Rosa Authorization API Standards discussion

[Anton de Winter]

Hello again,

This is a message to link you to the proposed authentication API for
OpenRosa client<->server communications. The page is here:
http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI .
Although this API has been discussed and mostly been agreed upon by
many members of the work group, please have a look over the specs
again and discuss any queries/issues here to ensure that everyone is
in fact in agreement. This should help us get this API formalized and
ready to use as quickly as possible.

Thanks to Munaf from Cell-Life for the great job on writing up the
Wiki page.

Cheers!
Anton

[Yaw Anokwa]

why do we include date time and mobile version in each interaction?

[Mitch Sundt]

Why would we not just move to RFC 2617? Can anyone comment on what would change?

The date time and mobile version headers should be moved into a different proposal for http header extensions.
What is the use case for them?

Mitch

--
Mitch Sundt
Software Engineer
University of Washington
msu...@cs.washington.edu

[Mitch Sundt]

After reading the RFCs, it seems like we should decide:

1) all http interactions MUST be HTTP 1.1
2) servers MUST conform to RFC2617 for returning one or more authentication schemes in their 401 challenge.  These define the authentication interactions that the server is willing to accept from the client -- e.g., Basic authentication, Digest, Negotiate (for e.g., Kerberos).
3) any server interactions MAY be unauthenticated
4) non-device (e.g., browser) interactions for which the server requires authentication MAY NOT support the OpenRosa Restricted Digest authentication scheme.  e.g., they are allowed to only support Basic or some other authentication scheme.
5) device-and-server interactions for which the server requires authentication MUST implement the OpenRosa Restricted Digest authentication scheme as detailed below.
6) device-and-server interactions for which the server requires authentication MAY implement other authentication schemes
7) the device MUST make every effort to proactively supply an Authentication: header line if the requested URI falls within the list of domain URIs covered by a previous authentication interaction.  This is to minimize the number of authentication challenges.

OpenRosa Restricted Digest authentication:

This is the Digest Access Authentication Scheme (RFC 2617 Section 3) constructed as a challenge with the following restrictions in that scheme request:

a) algorithm -- server MUST omit or specify "MD5"
b) domain -- server MUST specify to help device with proactive inclusion of Authenticate: header records.
b) qop  -- device MUST support all of: omitted, "auth", or "auth-int" ; server MAY request any of these
c) opaque -- device MUST return if supplied; server MAY supply this or omit it
d) stale -- device MUST make every effort to not prompt the user for username and password if this is TRUE but instead recompute the key with previously cached values for the username and password.
e) cnonce -- device MUST use a string representation of a random UUID for the cnonce.  I'm defining this largely so devices don't do something stupid like a compiled-in, fixed, string.  This random UUID only needs to be generated once at program start-up, if that makes the code easier.

Mitch

http://www.OpenDataKit.org
University of Washington
msu...@cs.washington.edu

[Jonathan Jackson]

Hi Mitch,

I agree we should move them to a header proposal and decouple the issues.  

My original request was to put these in the header so that we would always know what the app thought its version and time was at the exact point went it submitting to a server.  

This came from our real-world problem of not being able to determine the app version or time accurately.  On Nokia, if the battery completely dies and you do not set up the phone to sync to the cellular time, you can get very odd times for time-start and time-end.  Submitting the time the phone thinks it is in the header does not enable resolution of this problem, as the form could have been saved, the time changed, and then the form submitted.  However, if someone were so inclined they could make a best effort to resolve the most likely time-start and time-end times based on the timestamp header.

Similarly, with auto-update capabilities you might have one version of a mobile client creating an xform and another version submitting it. 

Both of these fields would be more for system management and debugging that day-to-day processing.  

thanks,

Jonathan

[Mitch Sundt]

Intriguing problem!

Thanks,

Mitch

[Anton de Winter]

Hi everyone,

There was a previous discussion about the Auth API a few months ago (see http://groups.google.com/group/javarosa-developers/browse_thread/thread/d7972bcc4719d9fb/98ecdbacfffaa662?q=authorization&lnk=nl&&pli=1 ), it looks like a number of the points mentioned by Mitch were agreed upon.  Overall it seems like Digest Authentication is the way to go.  

The last conversation on this spec stalled on the following issue:

The newer spec (RFC2617) supports a number of new features over the older spec (RFC2609) that we don't necessarily require.  

The newer features are optional, so I think that it seems reasonable to say that we support RFC 2617 and not necessarily implement the 

newer (optional) features.

Does anyone foresee any problems with this?

I've emailed Munaf, the author of the standards doc, to see if he can update it (also invited him to this group).

Cheers,

Anton   

[Mitch Sundt]

Hi Anton,

I don't think that is sufficient.  The specification should spell out what the device MUST support, and what the server MUST support.  There is still a lot of wiggle room in the RFC2069 and RFC2617 specs.

The list I sent is sufficient to:

• eliminate incompatibilities (e.g., algorithm) and nail the behavior down (1-7).
  
• ensure that reauths are kept to a minimum and user prompting at the device is minimized (e.g., handling of: domain, stale). 
  
• allows the server to pass a state handle to the device and expect it back (e.g., handling of: opaque).
• enforces good practice (e.g., cnonce values).

Within that framework, if we want the device to only be required to support RFC2069 then change:

b) qop  -- device MUST support: omitted; it MAY support all of: omitted, "auth", or "auth-int" ; server MAY request any of these and MUST accept a reply where qop is omitted.

as compared to:

b) qop  -- device MUST support: omitted, "auth", or "auth-int" ; server MAY request any of these.

-----
Mitch

mitche...@gmail.com

[Clayton Sims]

Supporting "auth-int" for large, encrypted payloads is kind of a pain (since you can't store it in heap, you've gotta run the whole payload build process, stream it through the MD5'er, then replicate that process bit-for-bit), and would probably add time to the implementation, but is probably worth it to get "auth".

-Clayton

[Mitch Sundt]

Good point.  An https connection gives an integrity guarantee, so it seems easier to just recommend moving to https if you have that level of security concern (and if you do, you're likely to want the privacy guarantee of https). 

And yes, I think getting "auth" support is useful.  RFC2617 suggested that the RFC2069 interaction had a number of security holes that the "auth" case fixed.

So... the device MUST support omitted and "auth" ?  Works for me.

Mitch

[Anton de Winter]

Just a quick update:  Munaf has updated the wiki doc, please have a look and let me/Munaf know if anything has been left out.

Thanks,
Anton

[Mitch Sundt]

Three edits:

(1) The first paragraph of the overview should be changed to say we are following RFC2617 with additional OpenRosa compliance requirements defined in the implementation section below.

(2) Implementation / OpenRosa Restricted Digest Authentication

Item 3 qop: change this to read:

device MUST support: omitted and "auth"; server MAY request any of these.

(3) Implementation / Parameters  -- strike this section in its entirety -- if needed, it should be a separate proposal.  I think this information is already handled in a different way by the Metadata proposal?

[Anton de Winter]

Looping munaf in just in case he's not on the thread...

[Munaf Sheikh]

done..
-----------------------------------------------------------------
Munaf Sheikh
(Cell-Life)

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

[Samson Gejibo]

 

Hi guys,

 

I was following interesting discussion on Authentication API. Now, I am looking for further documentation on security features so far implemented/planned on JavaRosa. Would you please provide me links for doc or summary of security features and mechanisms.

 

Thanks,

 

Warm regards,

 

_________________________________

Samson

PhD Candidate

Centre for International Health(CIH),

University of Bergen, Norway

[Yaw Anokwa]

does http://bitbucket.org/javarosa/javarosa/wiki/AuthorizationAPI
cover your needs?

[Samson Gejibo]

 

Thanks, apart from proposed secure authentication, did Javarosa implement security mechanism for data storage or data transport?  

--

__________________________________________________

Samson Gejibo

 

Centre for International Health (CIH)

University of Bergen (UiB)

Bergen, Norway

Mob: +4798123374

 

[Jonathan Jackson]

Hi Samson,

There is a PKI scheme that Clayton has implemented around ODK, but its not yet in ODK's trunk.  We have not implemented and "at rest" security for the RMS on J2ME phones.  

-J

[Samson Gejibo]

 

Thanks J. Clayton, can I expect the PKI scheme on ODK's trunk soon?

 

//Samson

[Clayton Sims]

Samson,

I'm working with Yaw and Carl on that, but have no ETA quite yet. 

-Clayton