Open Stack

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. 

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.
That said, they're all easily defeated by common malware techniques and
in my opinion, not to be trusted anyway...

Regards
-Rob

> -----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?
> >>
> >> 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
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130828/eed9b56c/attachment.bin>