Open Stack

Thank you Jeffrey for your detailed message. The Trusted-Platform-Module (TPM) would enable identifying the device without disclosing the actual device id .
TPM is found on servers on client devices these days and inexpensive.
http://opensecuritytraining.info/IntroToTrustedComputing_files/Day2-1-auth-and-att.pdf

Regards
Malini

-----Original Message-----
From: Jeffrey Walton [mailto:noloader at gmail.com] 
Sent: Tuesday, August 20, 2013 1:55 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Authenticating User and Workstation/Device

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-securit
>> y
>
>

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security