1. IEEE SISWG (P1619.3)‏ Messaging & Transport

2. AGENDA Transport Protocols & Channel Protection Messaging Layer Capability Exchange & Authentication Groups & Access Control Mechanisms Summary of Object structures Open items / discussion

3. 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.

4. 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.

5. Protocol The next few slides will give an overview of the protocol between the client and the server for certain common/critical operations.

6. 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.

7. 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.

8. 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.

9. 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)‏

10. 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)