1. KMIP Notes 1.3 – Security Attribute Security 15 May 2014 Chuck White – cwhite@semper-fortis.com 1

2. Thoughts on NIST SP 800-130, 800-152 2 Client needs to be able to wrap/unwrap attributes Server needs to be able to wrap/unwrap attributes Needs Link to a wrapping key Need to know the difference between Sensitive and Non-Sensitive attributes Same key for key material wrapping and sensitive attributes must be possible Separate key for key material wrapping and sensitive attributes must be possible Need a digest across both the key material and the sensitive attributes (one of the NIST requirements) Today’s focus in on discussing options to designate and secure security attributes

3. Where to start on Security Attributes Given the need for protecting security attributes, how do we go about implementing security metadata? (NIST SP 800-130 2.4 Framework Topics and Requirements) – What is a method to designate what metadata needs to be secure – What method should be used to associate wrapping keys with metadata.

4. What is a method to designate what metadata needs to be secure: Introducing the “z” Custom Attribute Current Custom attributes denote either client or server information z attribute is a custom security attribute z–”CustomSecurityAttribute” – could be client, server, or neither – z-x for Client – z-y for Server – z for generic or key specific security attribute

5. z-Attributes continued Note that have the “z” in front is to be able to quickly differentiate a custom security attribute from custom client and server attributes. Also require an association wrapping keys associated with encrypting the security attributes – Wrapping keys is a smart move and provides traceability with the Framework requirement for SP 800-130 (FR: 2.4) – Should work within the current Key Wrap specification This is a slight twist from Tim Hudson’s Recommendation at the F2F, main difference is that z becomes a custom attribute type of its own. – Mainly because some security attributes will be independent of the current client and server nomenclature. – For example, attributes associated with the security classification of the key

6. What Method should be used to associate wrapping keys with metadata: Security Attribute Security Options Wrapping is a good strategy and is an accepted form of security information in transit – so it’s a good starting point. Currently the Key Wrapping Specification can cover securing all the attributes associated with a Wrapped Key (KMIP 1.2 2.1.6) – This provides a means of moving to a NIST compliant approach with no additional effort – its already there

7. Additional Commands for Wrapped Attributes Need to account for registering Wrapped Attributes – Unwrap on register? – Unwrap on command after register? – Never Unwrap? What to do on Get and Get Attributes? – Do we need a wrap key attribute for Get Attributes?

8. KMIP 1.3 and NIST What is next? Defining the “mostly complete” set of z-attributes – Think along the lines classifications, authorized users, source information, security levels, etc. – With this model we could create a security attribute construct and work with profiles for implementation – Are there existing attributes that need to be considered sensitive: ie Cryptographic Algorithm, Cryptographic Length Defining commands to register keys with wrapped attributes Defining Commands for getting wrapped attributes Determining use cases and profiles – Hint: KMIP isn’t just for storage anymore.