Download
1 / 8
80 likes | 240 Views
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
E N D
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–”CustomSecurityAttribute” – could be client, server, or neither • z-x for Client • z-yfor Server • zfor 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 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
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.
