Open Stack

Hi Robert,

On Wed, Aug 28, 2013 at 12:56 PM, Clark, Robert Graham
<robert.clark at hp.com> wrote:
> Agree that a TPM seems like the obvious way forward in terms of system
> attestation, it doesn't make many guarantees about the systems fitness
> for purpose though.
TPM will cover a number of later Linux and Windows hosts, but its not
an option for many other workstations and devices, such as existing
PCs, low end PCs, Mac OS X, Android, and iOS.

> There are host-based endpoint-security products out there that aim to
> make certain guarentees about the state of a client device before it's
> allowed to join say, a VPN - it's not hard to see a Segway into doing
> something similar with these vendors but for accessing cloud resources.
Well, VPN is not available to some clients (iOS does not allow the
required options on raw sockets; and I imagine Windows Phone Store
Apps (formerly Metro) have a similar limitation). In addition,
wouldn't VPN mean a company would have to purchase an IaaS or PaaS
package instead of just storage to provide the requisite endpoint for
the security association?

In the absence of VPN, we seem to lack the higher level protocols to
perform the [additional] authentication with channel binding. In most
cases, the channel is not being bound correctly for the simple case of
{username,password}.

Bad:
  - send {username,password} in a basic_auth system
Not Better (worse?):
  - send {username,password,device,shared secret} in a basic_auth-like system

> That said, they're all easily defeated by common malware techniques and
> in my opinion, not to be trusted anyway...
Malware can be controlled through trusted distribution channels, code
signing, and sandboxing (among others). I don't think it can be
eliminated.

Linux, Windows, Mac OS X (and their mobile countercparts) will likely
be able to drive the risk down to acceptable or trivial levels.

Android's architecture is such that we will likely never be able to
control the malware.

Jeff

>> -----Original Message-----
>> From: Bhandaru, Malini K [mailto:malini.k.bhandaru at intel.com]
>> Sent: 25 August 2013 08:22
>> To: noloader at gmail.com; Bryan D. Payne
>> Cc: openstack-security at lists.openstack.org
>> Subject: Re: [Openstack-security] Authenticating User and
>> Workstation/Device
>>
>> 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?