1. IEEE P1619.3 Overview Matt Ball, Chair Sept 27, 2007

2. Outline l Project Authorization Request (PAR) l Goals and Priorities l Standards Committee Organization l Messaging and Grammar Options l Architecture Proposals l Other Key Management Standards l Web Links

3. IEEE Project Authorization Request l The IEEE-SA (Institute of Electrical and Electronics Engineers Standards Association) creates internationally recognized standards l Examples l IEEE 802.11 (Wireless Ethernet) l IEEE 1394 (Firewire) l Each IEEE standards group requires a Project Authorization Request (PAR) to define Title, Scope, and Purpose of standard

4. P1619.3 Project Authorization Request (PAR) l Title: l Draft Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data l Scope: l This standard specifies an architecture for the key management infrastructure for cryptographic protection of stored data, describing interfaces, methods and algorithms. l Purpose: l This standard defines methods for the storage, management, and distribution of cryptographic keys used for the protection of stored data. This standard augments existing key management methodologies to address issues specific to cryptographic protection of stored data. This includes stored data protected by compliant implementations of other standards in the IEEE 1619 family.

5. P1619.3 Goals and Priorities 1)To quickly create a standard that allows secure interchange of keys between cryptographic units that control stored data and key managers, and among key managers 2)Understand existing standards and use where possible to expedite the creation of this standard 3)Raise public awareness of P1619.3 and encourage adoption through marketing 4)Facilitate interchange by providing open source reference implementations

6. Schedule l Started in April 2007 l Preliminary Framework by end of 2007 l Start Sponsor Ballot by Jan 2009 l Complete by July 2009 (Sponsor ballot + resolution + publication)

7. IEEE SISWG Organization IEEE Computer Society Information Assurance (IA) Jack Cole, Chair Security in Storage Working Group (SISWG) Matt Ball, Chair Eric Hibbard, Vice Chair Fabio Maino, Secretary P1619 (Disk Encryption) Serge Plotkin, Chair and Editor P1619.1 (Tape Encryption) Matt Ball, Chair and Editor P1619.2 (Wide Encryption) Jim Hughes, Chair Charlie Martin, Editor P1619.3 (Key Management) Matt Ball, Chair Bob Lockhart, Editor Storage Systems (SS) Curtis Anderson, Chair

8. Current P1619.3 Members (Sept 2007) l Adaptec l Brocade l CipherMax l Cisco l Decru (NetApp) l Dell l Emulex l Hitachi Data Systems l Hewlett-Packard l IBM l Lexar Media l LSI Logic l Microsoft l NeoScale Systems l Optica l PMC Sierra l Quantum Corp. l RSA Security (EMC) l Seagate l Sun Microsystems l Symantec l Verisign l Visa International l Voltage Security l Wave Systems l WinMagic

9. P1619.3 Subcommittees l Project Management Standing Subcommittee (PM) l Architecture Standing Subcommittee (ARCH) l Name Space Adhoc Group (NS) l Operation and Objects Adhoc Group (OO) l Use Cases Adhoc Group (USE) l Transport Adhoc Group (TRAN) l Messaging Adhoc Group (MSG) l Reference Implementation Standing Subcommittee (RISS) l Compliance Standing Subcommittee (CpSS) l Conformance Standing Subcommittee (CfSS) l Wine Tasting Standing Subcommittee (WTSS)

10. Messaging and Grammar Options

11. Transport Protocol Options l HTTPS l TLS l IPSec l SCSI l Other

12. Messaging Format Options l XML Messaging l XML l XML RPC l XML SOAP l No XML l Binary Messaging l Freeform l Tag-Length-Value l ASN.1 DER l No Binary

13. Grammar l ASN.1 l ABNF l XML Schema l XML DTD l XML (SOAP grammar) l Other

14. Architecture Proposals

15. Diagram KM User Key Mgmt Server Cryptographic Unit Storage Medium Key Mgmt Server Cryptographic Unit Storage Medium replication, movement Key Archival P1619.0,.1,.2 data KM Ops KMS Ops KM Ops KM Ops KM Ops Key Backup (Stor. Medium) KM Backup KM Archive KM client

16. KM Server Provides Secure Key Repository, Key Lifecycle Management, Policy Management, Audit/Reporting and Secure Communications for KM Clients and KM Users KM Server Provides Secure Key Repository, Key Lifecycle Management, Policy Management, Audit/Reporting and Secure Communications for KM Clients and KM Users KM Client Communicates directly with KM Server using standard messaging and communications protocols such as XLM over TLS, XLM SOAP over HTTPS, or whatever we come up with. Communicates with CU Agent via Open API usually within the same system as CU Agent KM Client Communicates directly with KM Server using standard messaging and communications protocols such as XLM over TLS, XLM SOAP over HTTPS, or whatever we come up with. Communicates with CU Agent via Open API usually within the same system as CU Agent CU Agent (Optional) Provides translation from native CU protocols to KM Client API for storing and requesting keys, policies and other cryptographic information required to encrypt data at rest. Will usually reside on same system as KM Client. CU Agent (Optional) Provides translation from native CU protocols to KM Client API for storing and requesting keys, policies and other cryptographic information required to encrypt data at rest. Will usually reside on same system as KM Client. Cryptographic Unit (CU) Provides encryption of data either at rest or in flight. Uses message formats and protocols defined by appropriate standards bodies to communicate with a controlling entity (array, library, host OS, etc… Cryptographic Unit (CU) Provides encryption of data either at rest or in flight. Uses message formats and protocols defined by appropriate standards bodies to communicate with a controlling entity (array, library, host OS, etc… Key Management Services Components (NeoScale) P1619.3 KM Client API Name Space, Objects, Message Format and Transport Application Specific Communications NOTE: If it is in Red or in a Red box, it must be created by P1619.3

17. HP LTO4 Architecture

18. Ethernet SCSI Library (Medium to Large capability) Data/Backup Server Key Management Server Tape Drive** SCSI* on RS-422 (ADI) SCSI* (on pSCSI, FC, SAS, etc.) SCSI* on Ethernet Ethernet – XML/Soap? Library (Medium or minimal capabiility) Tape Drive SCSI* on RS-422 (ADI) * SCSI includes SPIN/SPOUT & IKEv2 extensions Some thoughts from IBM on protocols / interfaces SCSI* on Ethernet ** Ethernet capable tape drive

19. Library-based key management, drive- based encryption Quantum Web Management Application Host system/ backup application SCSI or FC Backup Admin SSL Authentication Key Reference ID Web Interface- Ethernet

20. Appliance-based key management, drive- based encryption Key Management Application Host system/ backup application SCSI or FC Backup Admin SSL Authentication Key Reference ID Web Interface- Ethernet

21. How to Identify the Key l Each key needs an identifier, called a Security Object Global Unique Identifier (SO_GUID) l Global uniqueness is necessary to allow for integrating two different key shares, or when sharing keys between companies.

22. Security Object Global Unique Identifier (SO_GUID) Proposals l Uniform Resource Identifier (URI) l Name Address Authority (NAA) l Random Number l Locally Assigned

23. URI-Based SO_GUID l Uses ICANN as the naming authority l Format: l kms:// / l Examples: l km://kms.example.org/key/dir1/dir2/key123 l km://example.com/key/dir1/%00%00%EA%05 l km://kms.bigbank.example.com/key/00010203040 5060708090A0B0C0D0E0F l km://example.net/policy/bizpolicy/storsecpolicy/km spolicy/keypolicy3

24. NAA-Based SO_GUID Bit Octet 76543210 0'n' (6E 16 ) 1'a' (61 16 ) 2NAA... NAA specific 9 10(MSB) SO_Handle n-1(LSB) ValueDescriptionName AuthorityReference 2IEEE ExtendedIEEE OUIT10/SPC-4 3Locally assignedNoneT10/SPC-4 5IEEE RegisteredIEEE OUIT10/SPC-4 All othersReserved

25. Random Number l Create a ‘probably’ global unique identifier by generating a sufficiently large random number l No need for a naming authority l Lacks metadata l Possibility of collision

26. Locally Assigned SO_GUID l To support existing implementations, we will need to support a ‘locally assigned’ system for describing identifiers l Locally Assigned identifiers have no assurance of global uniqueness, and will need special handling when migrating to new systems.

27. Related Standards l Trusted Computing Group (TCG) – Key Management Services Subgroup (KMSS) l OASIS Enterprise Key Management Infrastructure (EKMI) l Internet Engineering Task Force: KEYPROV (Key Provisioning) l ISO 11770 l SNIA SMI-S

28. Web Links l SISWG Homepage: l www.siswg.net www.siswg.net l E-mail Reflector: l http://grouper.ieee.org/groups/1619/email/ http://grouper.ieee.org/groups/1619/email/ l Information Assurance (Sponsor): l http://ieeeia.org/iasc/ http://ieeeia.org/iasc/

29. Questions?

30. Additional Slides IEEE Patent Policy Slides

31. Instructions for the WG Chair The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: l Show slides #1 through #5 of this presentation l Advise the WG attendees that: l The IEEE’s patent policy is consistent with the ANSI patent policy and is described in Clause 6 of the IEEE-SA Standards Board Bylaws; l Early identification of patent claims which may be essential for the use of standards under development is encouraged; l There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. l Instruct the WG Secretary to record in the minutes of the relevant WG meeting: l That the foregoing information was provided and the five slides were shown; l That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard; l Any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. l It is recommended that the WG chair review the guidance in the Standards Companion on inclusion of potential Essential Patent Claims by normative reference. Note: WG includes Working Groups, Task Groups, and other standards-developing committees. (Optional to be shown)

32. Highlights of the IEEE-SA Standards Board Bylaws on Patents in Standards l Participants have a duty to tell the IEEE if they know (based on personal awareness) of potentially Essential Patent Claims they or their employer own l Participants are encouraged to tell the IEEE if they know of potentially Essential Patent Claims owned by others l This encouragement is particularly strong as the third party may not be a participant in the standards process l Working Group required to request assurance l Early assurance is encouraged l Terms of assurance shall be either: l Reasonable and nondiscriminatory, with or without monetary compensation; or, l A statement of non-assertion of patent rights l Assurances l Shall be provided on the IEEE-SA Standards Board approved LOA form l May optionally include not-to-exceed rates, terms, and conditions l Shall not be circumvented through sale or transfer of patents l Shall be brought to the attention of any future assignees or transferees l Shall apply to Affiliates unless explicitly excluded l Are irrevocable once submitted and accepted l Shall be supplemented if Submitter becomes aware of other potential Essential Patent Claims l A “Blanket Letter of Assurance” may be provided at the option of the patent holder l A patent holder has no duty to perform a patent search l Full policy available at http://standards.ieee.org/guides/bylaws/sect6-7.html#6 Slide #1

33. 6.2 Policy IEEE standards may be drafted in terms that include the use of Essential Patent Claims. If the IEEE receives notice that a [Proposed] IEEE Standard may require the use of a potential Essential Patent Claim, the IEEE shall request licensing assurance, on the IEEE Standards Board approved Letter of Assurance form, from the patent holder or patent applicant. The IEEE shall request this assurance without coercion. The Submitter of the Letter of Assurance may, after Reasonable and Good Faith Inquiry, indicate it is not aware of any Patent Claims that the Submitter may own, control, or have the ability to license that might be or become Essential Patent Claims. If the patent holder or patent applicant provides an assurance, it should do so as soon as reasonably feasible in the standards development process. This assurance shall be provided prior to the Standards Board’s approval of the standard. This assurance shall be provided prior to a reaffirmation if the IEEE receives notice of a potential Essential Patent Claim after the standard’s approval or a prior reaffirmation. An asserted potential Essential Patent Claim for which an assurance cannot be obtained (e.g., a Letter of Assurance is not provided or the Letter of Assurance indicates that assurance is not being provided) shall be referred to the Patent Committee. A Letter of Assurance shall be either: a) A general disclaimer to the effect that the Submitter without conditions will not enforce any present or future Essential Patent Claims against any person or entity making, using, selling, offering to sell, importing, distributing, or implementing a compliant implementation of the standard; or b) A statement that a license for a compliant implementation of the standard will be made available to an unrestricted number of applicants on a worldwide basis without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. At its sole option, the Submitter may provide with its assurance any of the following: (i) a not-to-exceed license fee or rate commitment, (ii) a sample license agreement, or (iii) one or more material licensing terms. IEEE-SA Standards Board Bylaws on Patents in Standards Slide #2

34. Copies of an Accepted LOA may be provided to the working group, but shall not be discussed, at any standards working group meeting. The Submitter and all Affiliates (other than those Affiliates excluded in a Letter of Assurance) shall not assign or otherwise transfer any rights in any Essential Patent Claims that are the subject of such Letter of Assurance that they hold, control, or have the ability to license with the intent of circumventing or negating any of the representations and commitments made in such Letter of Assurance. The Submitter of a Letter of Assurance shall agree (a) to provide notice of a Letter of Assurance either through a Statement of Encumbrance or by binding any assignee or transferee to the terms of such Letter of Assurance; and (b) to require its assignee or transferee to (i) agree to similarly provide such notice and (ii) to bind its assignees or transferees to agree to provide such notice as described in (a) and (b). This assurance shall apply to the Submitter and its Affiliates except those Affiliates the Submitter specifically excludes on the relevant Letter of Assurance. If, after providing a Letter of Assurance to the IEEE, the Submitter becomes aware of additional Patent Claim(s) not already covered by an existing Letter of Assurance that are owned, controlled, or licensable by the Submitter that may be or become Essential Patent Claim(s) for the same IEEE Standard but are not the subject of an existing Letter of Assurance, then such Submitter shall submit a Letter of Assurance stating its position regarding enforcement or licensing of such Patent Claims. For the purposes of this commitment, the Submitter is deemed to be aware if any of the following individuals who are from, employed by, or otherwise represent the Submitter have personal knowledge of additional potential Essential Patent Claims, owned or controlled by the Submitter, related to a [Proposed] IEEE Standard and not already the subject of a previously submitted Letter of Assurance: (a) past or present participants in the development of the [Proposed] IEEE Standard, or (b) the individual executing the previously submitted Letter of Assurance. IEEE-SA Standards Board Bylaws on Patents in Standards Slide #3

35. The assurance is irrevocable once submitted and accepted and shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of those Patent Claims, or for determining whether any licensing terms or conditions are reasonable or non-discriminatory. Nothing in this policy shall be interpreted as giving rise to a duty to conduct a patent search. No license is implied by the submission of a Letter of Assurance. In order for IEEE’s patent policy to function efficiently, individuals participating in the standards development process: (a) shall inform the IEEE (or cause the IEEE to be informed) of the holder of any potential Essential Patent Claims of which they are personally aware and that are not already the subject of an existing Letter of Assurance, owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents; and (b) should inform the IEEE (or cause the IEEE to be informed) of any other holders of such potential Essential Patent Claims that are not already the subject of an existing Letter of Assurance. IEEE-SA Standards Board Bylaws on Patents in Standards Slide #4

36. Other Guidelines for IEEE WG Meetings l All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. l Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. l Don’t discuss specific license rates, terms, or conditions. l Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. l Technical considerations remain primary focus l Don’t discuss fixing product prices, allocation of customers, or dividing sales markets. l Don’t discuss the status or substance of ongoing or threatened litigation. l Don’t be silent if inappropriate topics are discussed… do formally object. --------------------------------------------------------------- If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt Slide #5