P2600 Hardcopy Device and System Security WG Meeting

1. P2600Hardcopy Device and System SecurityMarch 2006 Working Group Meeting Don Wright Director of Standards Lexmark International don@lexmark.com

2. Agenda Items • Thursday/Friday, March 2-3 • Welcome & Introductions • Update and Approve Agenda • Review and approve January Minutes • IEEE Patent Policy Review • 2006 Meeting Schedule • Update on TCG • Update on INCITS CS1 Working Group • Discussion with NIAP about CCv3 • Review of Action Items from January Meeting • Other Topics from e-mail

3. Agenda Items • Thursday/Friday, March 2-3 • Document Review: Clauses 1-9, especially • Clause 5 • Clause 8 • Clause 9 • Others • Document Review of PPs • Enterprise PP • SoHo PP • Public PP • High PP • Other items • Paying for evaluations • Next meeting details • Summarize and record action items

4. Minutes from January Meeting • Minutes were published shortly after the meeting. • They are available at:http://grouper.ieee.org/groups/2600/minutes/P2600-minutes-Jan2006.pdf • Any corrections or changes?

5. Instructions for the WG Chair • At Each Meeting, the Working Group Chair shall: • Show slides #1 and #2 of this presentation • Advise the WG membership that: • 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; • Early disclosure of patents which may be essential for the use of standards under development is encouraged; • Disclosures made of such patents may not be exhaustive of all patents that may be essential for the use of standards under development, and that neither the IEEE, the WG, nor the WG Chairman ensure the accuracy or completeness of any disclosure or whether any disclosure is of a patent that, in fact, may be essential for the use of standards under development. • Instruct the WG Secretary to record in the minutes of the relevant WG meeting: • That the foregoing advice was provided and the two slides were shown; • That an opportunity was provided for WG members to identify or disclose patents that the WG member believes may be essential for the use of that standard; • Any responses that were given, specifically the patents and patent applications that were identified (if any) and by whom. (Not necessary to be shown) Approved by IEEE-SA Standards Board – March 2003 (Revised March 2005)

6. IEEE-SA Standards Board Bylaws on Patents in Standards 6. Patents IEEE standards may include the known use of essential patents and patent applications provided the IEEE receives assurance from the patent holder or applicant with respect to patents whose infringement is, or in the case of patent applications, potential future infringement the applicant asserts will be, unavoidable in a compliant implementation of either mandatory or optional portions of the standard [essential patents]. This assurance shall be provided without coercion. The patent holder or applicant should provide this assurance as soon as reasonably feasible in the standards development process. This assurance shall be provided no later than the approval of the standard (or reaffirmation when a patent or patent application becomes known after initial approval of the standard). This assurance shall be either: a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement either mandatory or optional portions of the proposed IEEE standard against any person or entity complying with the standard; or b) A statement that a license for such implementation will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. This assurance is irrevocable once submitted and shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal. New text in red! Even newer text in blue! Slide #1 Approved by IEEE-SA Standards Board – March 2003 (Revised February 2006)

7. Inappropriate Topics for IEEE WG Meetings • Don’t discuss the validity/essentiality of patents/patent claims • Don’t discuss the cost of specific patent use • Don’t discuss licensing terms or conditions • Don’t discuss product pricing, territorial restrictions, or market share • Don’t discuss ongoing litigation or threatened litigation • 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.htmlThis slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt Slide #2 Approved by IEEE-SA Standards Board – March 2003 (Revised March 2005)

8. Officers No Change • Chair: Don Wright, Lexmark • Vice Chair: Lee Farrell, Canon • Secretary/Lead Editor: Brian Smithson, Ricoh

9. 2006 Meeting Schedule • April 3-4, Mount Laurel, NJ @ Okidata • May 23-24 Paris, @ HÔTEL ATALA • June 19-20, Camas WA @ Sharp • July 26-27 Rochester, NY @ Xerox • September 6-7 Boulder, CO @ IBM • October 23-24, Lexington KY @ Lexmark • December 11-12, Orange County @ Canon

10. Trusted Computing Group Update

11. INCITS CS1 : Cyber-Security Update

12. NIAP Discussion • Questions developed via e-mail • Nevo • What are NIAP requirements for encryption? • The requirement for encryption did not go away. The family that defined it did go away. • Is FIPS certification is a requirement? • Only for the US. • Chen • Based on previous feedback from NIAP, "The IEEE use of the term “High Security” in connection with an EAL2 Profile is misleading and could cause user confusion. Even in the public environment there has to be admin functions or maintenance functions that need to have a high level of assurance and protection to ensure the Public does not bypass or corrupt the functionality of the device." Therefore, Which EAL level will NIAP accept for HVA environment or Public environment?

13. NIAP Discussion (cont.) • Aubry • Does NIAP think keeping several CIMs (CIM for basic robustness, CIM for medium robustness…)? • Yes • When can we have a draft version of CIM for basic robustness using CC V3? Is it possible to have them looking on our mapping to check how far we are? • In a PP, I think that we can use FMI_CHO to let the ST choose between FIA_UAU.1 and FIA_UAU.2. However, if we want to have the same ST addressing the case of user authentication by the TSF and the case of the authentication by a third party, what should be done? • Put in an assumption that the environment will provide the authentication but include a note that the TOE may provide the authentication. We could also define local-user and remote-user where authentication can be done differently.

14. NIAP Discussion (cont.) • Aubry • In our PP Application Notes we have: “Since the HCD consists of many functions (e.g. copier, printer, scanner, etc) and the combinations of those functions are practicable (e.g. copier only, copier and printer), some HCDs need not to counter part of threats or to depend on part of assumptions. For example, it is obvious that the vendor or users of the stand-alone HCD do not have to consider the network-related threats or assumptions. In such case, the scope of the ST must be smaller than this PP. However, the ST should be considered to comply with this PP, if the appropriate and logical justification to show that the reduced threats and assumptions are complete, consistent and coherent must be included in the ST.” Is this acceptable for NIAP? • See the PKE PP for an example of doing something similar.

15. NIAP Discussion (cont.) • Aubry • Are there any plans for CC V3.1? Are there any security requirements known to be modified in V 3.1? Changes like: “Users may interact directly with the TSF without binding to a subject.” (an IP traffic, for instance) and “Users that need to be identified do not always need to be registered.” may be useful in our profile. • I’m not sure how to require user data encryption in HVA PP. I have tried to do it in the version 17a that I have sent to Brian. Is it possible to have someone taking a look on our IT requirements and helping us to identify major errors.

16. NIAP Discussion (cont.) • Smithson • Are you considering creating U.S. Government Protection Profiles based on one or more of our "commercial" PPs? If so, which PP(s)? Are our definitions of the operational environment useful and appropriate for the government? • The next two question apply only if you answer "Yes" to the one above • What can we do to our PPs to make it easy to adopt them to U.S.Government versions? • Is it possible for the U.S. Government versions to be a superset of the commercial version, such that if a product is certified against the government version then it would also be certified for the commercial version? • We have not identified any OSPs. However, we are designing our PPs around EAL2, and at least in the case of our High Value Asset PP, we are targeting an operational environment in which legislative or regulatory requirements may apply. For our "commercial" PPs, should we identify OSPs to be enforced by the TOE? By the operational environment? • If there is a US government version of the any of our PPs, would you add OSPs that would describe government requirements? • Where should we place our definitions of subjects, objects, operations, and users? At the beginning of the SFR section? In its own section? Or ???

17. NIAP Discussion (cont.) • Smithson • The following are regarding CIM instruction 5, "content and outline of a PP": • Will NIAP still require the four appendices? (References, Glossary, Acronyms, and Robustness Environment Characterization) • Appendix B, Glossary, contains many terms that are not used in our PP. Should we delete unused terms from our glossary? • Will there be an updated version of the text for Appendix D? • How is FDP_ISA used? Can you give an example, or an example of how we might use it in P2600?

18. Group General Action Items • Update web site with March & April meeting details – done • What do we do now about CC V3? • Focus on other parts of the std • Resolve the issue of HVA and EAL levels (other PPs, too) • Object/Subject definition consistency • Etc.

19. Action Items from Previous Meetings • Review entries in P2600-action-items excel spreadsheet • Convert clause 1-9 to IEEE format - done • Move old clause 8 annexes into clause 9. - done • High: • Smithson will roll Public changes into HVA PP. - done • SoHo: • Thrasher/Aubry to resolve issue to user identification and change SoHo PP accordingly. - open • Other changes from Public to be rolled into SoHo by Smithson - done • Public: • Put T.TSF.CONF.AB back into Public PP - done • Other issues are highlighted in the 16a document - done

20. Issues raised on e-mail • Aubry: CIM Mapping • I made a new version of the CIM mappings for CC V3. I have tried to take into account:1) Brian requirement to specify when it is a basic robustness threat or a medium one2) Don requirement to specify when the threat it is already covered by our PPs. As the name of the threat may be misleading and the mapping between a given threat and the IT requirements necessary to cover the threats are not the same in our PPs and in CIM, I have decided to flag only the IT and assurance requirements as new or already included.Remark: The medium robustness CIM targets an EAL4. The associated assurance requirements will always be new for us (because we are targeting EAL2). • cim_med_CCV3_V2.doc

21. Issues raised on e-mail • Smithson: • I think we're missing an important component in our threat descriptions in clause 7 (and also in the PPs): the threat agent. CCv3 (part1 p48 line206 in particular) states that a threat consists of a threat agent, an asset, and an adverse action by the agent on the asset. This is fairly standard practice for describing threats. However, we generally refer to the agent as an "attacker", but we don't make further qualifications except for skill and equipment. I think we should consider identifying the threat agent more clearly, and if possible, use the "Actor" definitions in Table 2 of the PPs. This should help clarify the threat and also the appropriate and sufficient countermeasure. • T.TSF.CRED (in HVA and Enterprise) doesn't really address T.TSF.CRED.DISK. Unfortunately, that particular subthreat doesn't fit with the others (.NET, .EM, .MGMT, and .GUESS). It is more like T.UD.SALVAGE. Perhaps we should rename this threat T.TSF.SALVAGE and deal with it separately? • Section 2.1 isn't correctly written. There is no "strict conformance" to CC. Instead, it should say that it is "Part 2 conformant" (or "Part 2 extended") and "Part 3 conformant" (or "Part 3 extended"). See CCv3 part1 pg34-35 sec 9.4. • Section 3.3 intro could really use some work. It looks like it was written by a committee :-) • Section 3.3.X -- it might add clarity (or complexity, I'm not sure) if we subsectioned our assumptions as 3.3.1 Physical, 3.3.2 Personnel, and 3.3.3 Connectivity. See CCv3 part1 pg48 secA.6.4. – leave as is.

22. Issues raised on e-mail • Thrasher: • We need to consistently define subjects, objects, operations across the board for all of the PP's. • PP authors need to make consistent by “merging” • We need to account for the possibility that in some cases (like a network connection being "authenticated: using address filtering) the user is a machine not necessarily a person. • Make clarification as described while working on above. • Also that in the current CC V3.0, users cannot directly interact with objects, they can only interact with subjects that provide access to objects......BTW one of the comments/requests against CC V3.0 review that may be addressed in CC V3.1 is direct user access to objects. • NIAP acknowledges this.

23. E-Mail Items • Smithson • Section 3.2 OSPs: are we really dealing with this concept correctly? See CCv3 part1 pg49 secA.6.3. I'll put this on the list of questions for NIAP, also. "OSPs are rules, practices, or guidelines. These may be laid down by the organization controlling the operational environment of the TOE, or they may be laid down by legislative or regulatory bodies. OSPs can apply to the TOE, the operational environment of the TOE, and/or the development environment of the TOE. Examples of OSPs are: - All products that are used by the Government must conform to the National Standard for password generation and encryption; - All products that are used by the Bank, must be CC-certified with the EAL 4 + ADV_IMP.2 assurance package; - All system administrators that have access to the Department File Servers must be vetted to the level of Department Secret." • No action required • I think we need to insert a new section 5, "Extended Component Definitions". Even though it would likely be empty, it seems to be one of the "mandatory contents" of a PP. See CCv3 part1 pg65 secB.2. (Is it mandatory if the section is empty?) • No action required • Where do the definitions of subjects, objects, operations, and users belong? It wasn't clear to me from the CCv3 documents. I don't see it in the PP outline on CCv3 part1 pg56. I'll put this on the list of questions for NIAP, also. • Beginning of SFRs or Application Notes.

24. Document Section Status Editors Assigned: • Clause 1 & 4 – Don W. • Clause 2 & Informative References – Don W. • Clause 3 (definitions) -- Alan Sukert • Clause 5 (environments) – Peter C. • Clause 6 (assets) – Brian V. • Clause 7 (threats) – Jerry T. • Clause 8 (Mitigation) – Tom H. • Clause 9 (Best Practices) – Don W. • Enterprise PP -- Ron Nevo • High Value Asset PP – Brian Smithson • SoHo PP - Carmen Aubry • Public PP - Nancy Chen • Other Annexes – Smithson/Sukert

25. Document Review • Operational Environments • Operational Environment A • Protection Profiles • Protection Profile A (=HVA) • Protection Profile B (=Enterprise) • Protection Profile C (=Public) • Protection Profile D (=SoHo) • “Protection Profile for Hardcopy Devices in Operational Environment A”

26. Document Review • Drafts needing most review • Clauses: • 5 – Will be updated to use “Operational Environment A,” etc. • 8 – OK • 9 – OK • High • Enterprise PP • Public • SoHo PP • Others clauses • PP Annexes – OK

27. Document Review: High • Review Draft number 17a • Now Protection Profile A, EAL 3

28. Document Review: Enterprise PP • Review Draft number 17b • Now Protection Profile B, EAL 2

29. Document Review: SoHo PP • Review Draft number 17a • Now Protection Profile D • ISSUE: User authentication for printing – protecting the user document data • Take out the UD threats • Don’t include user authentication for print • Add back in threats to HCD’s integrity (“proxy”, “sw.update”) • Write PP-D to EAL1 / Low Assurance Level

30. Document Review: Public PP • Review Draft number 17b • Now Protection Profile C, EAL 2

31. Next Meeting Details • April 3-4 • Where: Okidata     2000 Bishops Gate Boulevard Mount Laurel, NJ 08054 • Hotels (ask for the Oki guest rate): • Courtyard - Mt Laurel rate $118.00http://marriott.com/property/propertypage/PHLML • Doubletree - Mt Laurel rate $124.00 includes breakfasthttp://doubletree.hilton.com/en/dt/hotels/index.jhtml?ctyhocn=PHLFRDT • StayBridge Suites - Mt Laurel rate $89.99 (studio) $99.99 (1 Bedroom) includes breakfast http://www.ichotelsgroup.com/h/d/sb/1/en/hd/blnml • Wyndham Hotel - Mt Laurel rate $89.99 http://www.wyndham.com/hotels/PHLMT/main.wnt

32. Next Meeting Details

33. Next Meeting Details

34. Action Items for April • Convert all sections to new Operational Environment names • Convert all sections to new PP names • Convert HVA to CIM Medium @ EAL 3 • Convert PP-D (SoHo) to EAL 1/Low Assurance • Harmonize Subject/Object implementation • Sharp: Details of meeting in Camas WA

35. Backup Slides

36. Mailing List and Web Site • Web Site: http://grouper.ieee.org/groups/2600 • Mailing list: • Listserv run by the IEEE • An archive is available on the web site • Subscribe via a note to: listserv@listserv.ieee.orgcontaining the line:subscribe stds-2600 • Only subscribers may send e-mail to the mailing list. No Change

37. Project Schedule from Sept Meeting • The PAR included estimates of the end-points of the schedule: • Initial ballot through IEEE (Lab get this as well) • Do needed recircs to get close • Run through the lab • Recirc the lab’s final changes if any • Turn around the clause 1-8 changes before Dec. Meeting • Merge section together for December meeting • Get all PPs in CCv3 by December meeting • Form IEEE Ballot Body in 1Q06