KMIP Notes 1 3 Security Attribute Security 15

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

Thoughts on NIST SP 800 -130, 800 -152 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 2

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.

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–”Custom. Security. Attribute” – could be client, server, or neither – z-x for Client – z-y for Server – z for generic or key specific security attribute

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 F 2 F, 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

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

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?

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.