Open Stack

Hi Doctor,

I'm going to address these out-of-order. My apologies if it does not
help the flow.

> Understanding this will guide the discussion and make it easier for others to chime in.
Here is some background to help understand why I am asking. Below is
from my limited experience in Federal, DoD, and US Financial. Its a
bit wider than just device provisioning, but I hope it paints a more
complete picture.

We want to classify our data, and then allow access to the data based
on the user, their role, and their environment. For simplicity,
imagine low, medium, and high value data classifications:

  * low - personal email, personal pictures, personal music
  * medium - private information such as personally identifiable information
  * high - FERPA, HIPPA, M&A, pending litigation, executive compensation

Information covered by federal law such as FERPA and HIPPA (and other
state laws) is often elevated to high because of the risk of financial
and reputational loss or harm. Firms operating in healthcare and
education often mishandle the data because they don't realize there's
more to security than the padlock in the browser.

Low value data, such as personal email accounts, pictures, and music
almost always can use SSL/TLS with a username/password. The risk of
financial and reputational loss or harm is usually low. Who cares if
personal pictures get accidentally leaked because the user re-used his
or her password; or a keylogger grabbed the password? (This is what
many others think, its not my personal feeling).

Medium value data, such as account numbers, employee lists with social
security numbers, Single Sign-On passwords, need some attention. We
might allow username/password over SSL/TLS, but require a hardened
channel (for example, proper channel binding or certificate/public key
pinning). We also require certain client configurations. For example,
the workstation or device must be approved or managed, and a thin
client like a web browser must not cache or store the data. A
browser-based application can be used, but the risk must be accepted.
The risk of financial and reputational loss or harm can be
non-trivial.

High value data, such as educational records, medical records, mergers
and acquisitions, pending litigation, executive compensation, and long
term strategic planning requires a fair amount of diligence. We want
the user authenticated, and usually with two factors; and the
workstation or device approved. In addition, we want a hardened
channel and hardened client. A browser-based application usually won't
suffice here. The risk of financial and reputational loss or harm can
be significant.

When working in US Financial, I saw a number of "Board Pad"
applications (I was a security architect in the risk department).
Executives and Directors wanted something to take the high value data
into board meetings. I saw the full range - from browser-based
application using PDF encryption to native applications with built in
office libraries for document viewing and annotations. 2nd factor
crushed them all because corporate policy required it when handling
high value data.

BYOD is really muddying the waters because we can provision or approve
the device, but we can't really manage it well. For example, we can't
instruct a web browser to delete all cookies, web pages, etc.
Additionally, if the radios are switched off then we can't send
management commands to the device which has an app with MDM component.
So we have to be careful about what we allow access to from the cloud
in the first place.

Its also noteworthy that a organization's workstation or corporate
supplied laptop often has a number of security controls not available
to a phone or tablet. For example, its hard to bypass full disk
encryption implemented in the hardware and managed by the firmware (if
implemented correctly). The same cannot be said about an iPad, where
powering it on serves up all keys with NSFileProtectionNone (Wifi
passwords, LDAP passwords, Exchange passwords, VPN passwords, etc).

> What type of device level authentication did you have in mind?
Either preshared secret or public/private key pairs. The preshared
secret or private key would be loaded upon provisioning the device
(and the public key would be circulated as expected). If the data
sensitivity warrants, we also want an OTP.

Perosnally, I'm a big fan of preshared secrets and passwords because
they are easy to work with and do not suffer all the systemic problems
of PKI and client certificates. Preshared secrets and passwords get a
black eye because our handling and management has been so poor (in
general).

You can't use GetDeviceId-like APIs for provisioning because built-in
UUIDs are not available due to advertisers tracking abuse. In
addition, some of the newer GetDeviceId APIs allow the user to reset
the UUID served up to an application to thwart tracking. Also, the
built-in UUIDs, MAC Addresses, etc could be aprtial or completely
guessable or leak information. So you have to use a preshared secret.

Unattended key storage is a problem without a solution, so the secret
or private key would simply have to go in a Keystore, Keychain, etc. I
believe the folks on the WebCrypto Working Group are trying to answer
some of the questions related to: how are secrets created, how are
they put in the store, how are they accessed once in the store, and
how are they used once in the store, etc (among others).
http://www.w3.org/2012/webcrypto/.

> For example, how would you expect a device to prove it's identity to the cloud?
Well, that's a problem at the moment, since I'm not aware of the
protocols :) I have not been able to locate them in the literature
using Google Scholar. I recently asked on sci.crypt
(https://groups.google.com/d/msg/sci.crypt/Y1aAJAnXia4/srwCu5SsctEJ).
My failures don't mean they don't exists - just that I have not been
able to locate the formal treatment.

Naively, the device name and device secret could be sent similar to
basic_auth. However, we know basic_auth has some problems in practice:
the scheme serves up all the information to any server that provides a
certificate. The real problem is the outer encryption tunnel is not
properly bound to the inner authentication mechanism. So sending twice
the sensitive information (user and device secrets) is probably a bad
idea.

When using protocls that properly bind channels, such as TLS-SRP and
TLS_PSK, I'm not sure the additional device information can be
pigeon-holed into the existing protocols.

I'm beginning to think the solution - for now - is to use well
known/understood primitives twice. But I'm not sure its the best
solution. For example, use TLS-SRP and TLS_PSK to authenticate the
user. At this point, the user is authenticated but has no
entitlements. Then, use device authentication to add entitlements or
received during user authentication. After user and device
authentication, the user will be able to access resources (i.e.,
authorizations).

When using the device to fine-tune entitlements or authorizations, I
don't believe we can serialize the authentication (like a SecurID or
OTP). A device secret is private, and it should not be put on the wire
like a password in basic_auth since it never changes (unlike a SecurID
or OTP). So should the protocol include a second CHAP step, or should
it run a second instance of TLS-SRP and TLS_PSK in the first
instance's tunnel?

> Understanding this will guide the discussion and make it easier for others to chime in.
To revisit and summarize:

  * classify data on the server (i.e., in swift) via the metadata
  * authentication system needs to authenticate the device for medium value data
  * authentication system needs to accept a second factor (i.e., OTP)
for high value data

And in Federal or DoD:

  * authentication system needs to accept CAC/PIV cards

Sorry about the verbosity.

Jeffrey Walton

On Tue, Aug 20, 2013 at 12:11 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
> Jeffrey,
>
> I'm not aware of something like this that is already in place.  However, I
> am curious about your requirements as this may be something one could put
> together with existing tools.  What type of device level authentication did
> you have in mind?  For example, how would you expect a device to prove it's
> identity to the cloud?  Understanding this will guide the discussion and
> make it easier for others to chime in.
>
> Cheers,
> -bryan
>
>
>
> On Tue, Aug 20, 2013 at 7:55 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>>
>> Hi All,
>>
>> I've been through the OpenStack APIs, but I don't believe I've seen a
>> solution to my problem. I'm looking for a method to authenticate both
>> the user and his/her workstation or device.
>>
>> In this scenario (or use case), the user would be given access to
>> low/medium/high value data if on their workstation; but only access to
>> low value data if on a mobile device.
>>
>> Does OpenStack provide a solution to workstation/device provisioning
>> and authorizations based on the hardware and data sensitivity levels?
>>
>> Thanks in advance,
>> Jeffrey Walton
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>