Open Stack

Hi Nathan,


Sorry about the late reply.

> Is there anything in particular about this effort that you want to
> discuss, or do you just want to follow what is happening?
I'd like to follow and point out any issues that percolate up that I can spot.

I'd be interested in knowing what the threats are. Are the adversaries
passive, so that Message Security only want to limit information
disclosure from, for example, a misconfigured KVM. Or are they active,
where Message Security is trying to defend against someone trying to
break out of their sandbox to {decrypt|inject|delete} other tenant
traffic and control messages.

Also, looking at the key derivations, I think the key derivation
inputs should include a version number, too:

  Key Derivation inputs:
    Time.T = The time in the request
    TTL = Time To Leave, validity in seconds from Time.T
    Svc.A = the sender service name
    Svc.B = the receiver service name
    Key.A = the sender long term key
    Rnd.Salt = a random salt used for the extract function
    Rnd.Key = the Key used as input for the expand function
    Ls = Length of Signing Key (128bits)
    Le = Lenght of Encryption Key (128bits)

Otherwise, it might work out that the protocol is susceptible to
downgrade attacks like WinZip ("Attacking and Repairing the WinZip
Encryption Scheme",
http://homes.cs.washington.edu/~yoshi/papers/WinZip/winzip.pdf).

I also think the Signature Scheme could benefit from a "usage" label
on the "SignKey"):

     Signature = HMAC(SignKey, (Version || MetaData || Message))

Otherwise, you might be able to get one component to do things for
another component under the same key because the same key is used for
everything. Adding a usage label ensures distinct keys are used so
other components can't accidentally use the same key.

I'm not convinced the time-based scheme has helpful security
properties. Time is notoriously difficult to use correctly, and
everything I have rolled in practice uses counters.

I'd also be interested in hearing more about Provisioning and Key Exchange.

For what its worth, I like shared secret systems. They are orders of
magnitude easier to work with than public key based stuff. Shared
secret systems don't need to confer trust and can properly bind the
channel (not to mention the perverted joke called PKI and PKIX using
public CAs that don't warrant a damn thing). Most of the problems we
have with shared secrets and passwords is due to our own mishandling
of the sensitive data.

Jeff

On Sat, Nov 30, 2013 at 2:44 PM, Nathan Kinder <nkinder at redhat.com> wrote:
> On 11/29/2013 12:49 AM, Jeffrey Walton wrote:
>> Does anyone know if there's going to be any calls covering Message
>> Security as proposed at
>> https://wiki.openstack.org/wiki/MessageSecurity? I'd be very
>> interested in listening in.
>
> Hi Jeff,
>
> I'm not sure if there are any actual calls scheduled, but this was a
> discussion topic on the Keystone weekly IRC meeting last week.  I expect
> that it will be a topic this coming week as well.  You might want to
> join in:
>
>     https://wiki.openstack.org/wiki/Meetings#Keystone_team_meeting
>
> The document you reference needs some updating, as I feel that it dives
> into some low-level detail without providing enough high-level
> background for those who aren't familiar with similar key distribution
> schemes.  I plan to take a pass at cleaning this up in the next few days.
>
> Is there anything in particular about this effort that you want to
> discuss, or do you just want to follow what is happening?
>
> Thanks,
> -NGK
>
>>
>> Thanks in advance,
>>
>> Jeff
>>
>> FYI|PS: Dr. Rogaway is providing royalty free, irrevocable licenses
>> for OCB mode in open source projects
>> (http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm). OpenSSL's grant
>> can be found at
>> http://wiki.openssl.org/images/6/66/OCB-patent-grant-OpenSSL.pdf.
>>
>> OCB is the most efficient AE and AEAD mode available (as far as I
>> know). When operating in OCB mode, there's no need for combining
>> privacy modes like CBC with integrity protections like HMACs; nor is
>> there a need for key derivation functions to ensure key independence.
>>
>> Other AEAD choices include the usual suspects, such as CCM, EAX and
>> GCM mode. But they are less efficient than OCB due to Dr. Rogaway's
>> patent.
>>
>> And +1 for not choosing a mode like EAX Prime for message security
>> like the smart grid ;)
>>
>> ---------- Forwarded message ----------
>> From:  <gerrit2 at review.openstack.org>
>> Date: Fri, Nov 29, 2013 at 12:55 AM
>> Subject: [Openstack-security] [openstack/identity-api] SecurityImpact
>> review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
>> To: openstack-security at lists.openstack.org
>>
>> Hi, I'd like you to take a look at this patch for potential
>> SecurityImpact.
>> https://review.openstack.org/40692
>>
>> Log:
>> commit b775259ef1c06884985521fbba7cabc30884565a
>> Author: Simo Sorce <simo at redhat.com>
>> Date:   Wed Aug 7 14:16:28 2013 -0400
>>
>>     Key Distribution Server
>>
>>     API for distribution of keys in support of:
>>     https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
>>
>>     SecurityImpact
>>
>>     Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df