- IEEE Security in Storage Working Group

IEEE SISWG (P1619.3)
Messaging & Transport
AGENDA
•
•
•
•
•
•
Transport Protocols & Channel Protection
Messaging Layer
Capability Exchange & Authentication
Groups & Access Control Mechanisms
Summary of Object structures
Open items / discussion
Transport Mechanisms
• TCP/IP is the first network protocol that will be in
scope. (T10 covers key transfer over SCSI)
• TLSv1/SSLv3/IPSec/None will be the supported
channel protection protocols. (TBD: Supported
Ciphers)
• If the channel is not encrypted, then KM must wrap
keys prior to dispatching to client. The client must
have pre-exchanged keys setup for wrapping, else
the KM will reject the request.
Messaging Layer
• The two mandatory KM message exchange
mechanisms are SOAP & DER encoded ASN.1.
• ITU-T X.694 will be used to represent both formats
(WSDL + ASN.1 schema)
• If XML-RPC is required, then ASN.1 with XER
encoding would be the approach.
• Changes to D1 are being made. A first draft of the
messaging schema will be available in about 4 weeks.
Protocol
The next few slides will give an overview of
the protocol between the client and the server
for certain common/critical operations.
Capability Exchange
• KM Client establishes a transport channel with the
KM server.
• KM Client then sends its capabilities to the Server
using the Capability Object
• KM Server picks one of the ‘n’ that have been sent by
the client (SSL-like) or terminates the connection if it
encounters an unsupported capability.
• KM communicates its choice using the Capability
Object.
Authentication
• Every KM client is submitted with a Credential Object which indicates
the type and the actual credentials if necessary.
• If authentication is done @ the channel level (X509 attribute of an SSL
client certificate), then the credential field of the Credential Object is
NULL.
• Login Session creation is optional. In case username /password is the
chosen authentication mechanism, the credential field of the
Credential Object would be un/pwd.
• When a KM client requests an explicit login action, it would get a
Credential Object from the KM server with a credential type of
session and the session-id as the value of the credential.
• The authentication protocol must be extensible so that it can be
plugged into a customers SSO/CA system. The use of pattern
matching CA authenticators are recommended on the KM.
Objects
[Brief summary of prior presentation]
• Definition of Key, Client, DataSet & Policy
Objects.
• Notion of Key, Client & Policy Static (explicit
add/delete) & Dynamic Groups (pattern
based).
• Access control and policy enforcement by the
KM is enforced at a group level.
Objects
•
•
•
•
•
[Changes/Clarification from prior presentation]
Introduce the notion of a KeyManager Object to work in
conjunction with Distribution /Replication Policies.
Introduce the notion of Mandatory (Key, Client, etc) &
Optional (Distribution Policy) objects.
Introduce the notion of objects that are server only (Groups)
& server/client (the rest) objects.
Groups are managed via KM admin operations.
Specification is in the final stages of being updated to
incorporate these changes. (ETA – 2 weeks)
Open Items
• Cipher suite for Channel Encryption.
• 3DES
• AES (128, 256 bit)
• Key Exchange and channel dependencies
• Strength of wrapping key vs. encryption key (channel
strength should match or exceed encryption key strength,
based on Policy)
• Asynchronous operations between KM client and KM server –
Mandatory? Optional? (allow optional tagging of
commands/responses)