P2600 Hardcopy Device and System Security May 2005 Working Group Meeting

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

2. Agenda Items • Thursday/Friday, May 19-20 • Welcome & Introductions • Update and Approve Agenda • Review and approve April Minutes • IEEE Patent Policy Review • Update on 2005 Meeting Plan and Schedule • Update on TCG • Review of Action Items from April Meeting • Other Topics

3. Agenda Items • Thursday/Friday, May 19-20 (cont.) • Reorganization of document (Smithson e-mail of May 11) • Document Review: Section 1, 2, 3, High Security PP • From Submitted Comments only • Document Review: Enterprise PP • Document Review: SoHo PP • Other PPs • Other items • Summarize and record action items

4. Minutes from April Meeting • Minutes were published shortly after the meeting. • They are available at:http://grouper.ieee.org/groups/2600/minutes/P2600-minutes-Apr2005.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 and prior to approval of the standard (or reaffirmation when a patent or patent application becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of 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 shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period. Slide #1 Approved by IEEE-SA Standards Board – March 2003 (Revised March 2005)

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 • Chair: Don Wright, Lexmark • Vice Chair: Lee Farrell, Canon • Secretary/Lead Editor: Brian Smithson, Ricoh • Other Editors: • Jerry Thrasher • Ron Bergman • Ron Nevo – HS PP/Enterprise PP • Yusuke Ohta – HS PP/Enterprise • Carmen Aubry – SoHo PP

9. 2005 Meeting Schedule • July 11-12 -- SFO/San Jose (Apple) with PWG • Sept 15-16 -- New Jersey @ Ricoh • Oct 24-25 -- New Orleans with PWG • Dec 13-14 -- San Diego

10. Trusted Computing Group Update • Next TCG Meeting will be June 21-24, 2005 in Amsterdam • Brian will try to have Hardcopy group’s meeting in the evening to accommodate participants unable to travel to Amsterdam. • No other news since last meeting.

11. Group Logistical Action Items • Update web site with April meetings contents - done • Slides • Minutes • Etc. • Update web site with May 19-20 Toronto meeting details - done • Update web site with preliminary July 11-12 San Jose meeting details – done

12. Action Items from Previous Meetings • Section 1 updates (Brian S.) • Add Maintenance phone connections to drawings (Complete) • Update Bibliography • Add terms from section 2 (Proficient, Bespoke, etc.) • Reference mitigation techniques in sect 3 rather than use the ones from the NIST document. • Define Assets (from section 3) • Add acronyms from section 2 & 4 • Add explanatory text talking about choosing a target security environment based on asset value rather than just the name of the environment. E.g. A SoHo environment may have high value assets and should use enterprise PP instead. • Section 2 updates (Tom H) • Cross check section 2 with original vulnerabilities list – Complete • Unlocked operator Panel - complete • Section 4 team to verify which security environment’s PP are applicable to each threat (Section 4 team plus Tom H) -- Threat Analysis in progress • Decide if we want to include the security environment columns in final std -- Open

13. Action Items from Previous Meetings • Section 3 • Complete missing sections – Largely complete • Move asset section to section 1 – Open • Continue to work on actual recommendations for each threat. Align this section with section 2 threats. – Aligned and largely complete • Section 4 • HS draft – complete • Enterprise – multiple drafts circulated • Soho (Carmen Aubry) – draft available • Public assigned to Jean Claude of Océ - open

14. Action Items from Previous Meetings • Risk Assessment (H/M/L) by threat by environment – who? (In progress) • How valuable is the asset? • How difficult is it to execute the threat? • Sharp, Ricoh, Oce after meeting

15. Other Issues From Dave Freas: • In order to get a profile NIAP certified as a government profile, NIAP has some consistency guidelines that need to be followed (within reason). I assume you have reviewed these already, but I have not seen them explicitly referenced in the documentation. The website for this info is: http://www.niap.nist.gov/pp/ci_manuals.html. NIAP specifically splits their consistency manuals into 3 different robustness levels where the robustness level is defined as a characterization of the strength of a security function, mechanism, service or solution, and the assurance (or confidence) that it is implemented and functioning correctly. • DoD has three levels of robustness: • Basic: Security services and mechanisms that equate to good commercial practices. (EAL2) • Medium: Security services and mechanisms that provide for layering of additional safeguards above good commercial practices. (EAL4) • High: Security services and mechanisms that provide the most stringent protection and rigorous security countermeasures. (EAL?) • Each level has requirements as to what needs to be included in the profile. We’ll need to decide how our existing profile levels (High security, enterprise, SOHO) correlate to the robustness levels. While NIAP has guides for Basic and Medium robustness, they do not have a finalized guide for High robustness. How, if at all, should we use this guidance?

16. Basic Robustness Environment Analysis The following are the results of the examination of the NIAP Basic Robustness Guidelines (identified by Daivd Freas) conducted during the meeting. The numbers correlate to the 26 instructions. • Characterize Robustness Level • New text to be pasted into an Appendix D. See instruction #5 for the layout of the document. • Minor edits may be necessary to make it read better world wide (e.g. replace DoD with US DoD) and to insure general consistency with the rest of the Std. • Accommodating Software Only TOEs • Not applicable. • Uses of Basic Robustness • “suggested” text provided but the instruction seems to just want some discussion about robustness. • Assurance Requirements • Adds ALC_FLR.2 and AVA_MSU.1 to EAL2 • Initial assessment = reasonable for us.

17. Basic Robustness Environment Analysis • Content and Outline of a PP • There are some differences between the outline provided and our current layout. Some are just name changes others may need to be created if not already present • Format of the Title Page • Would probably be required for the PP actually submitted to NIAP. Might not be present in the actual standard. • Assumptions • Does not appear to be a problem; we will probably need to use A.PHYSICAL instead of A.LOCATION. • Describing Threats • Suggested text will need to be edited and included. • Will have to check our threats against the instructions for appropriateness.

18. Basic Robustness Environment Analysis • Threats, Policies, Objectives & Requirements • We will need to carefully examine the information in this instruction and modify the PPs appropriately. Not all the threats, policies, etc. will necessarily have to be included. (See Table 7 in document) • Specifying Requirements on the IT Environment • No IT environment requirements in our PP at this time. • What about user authentication using LDAP? We currently assume it is all inside the TOE but mention that some implementations may instead have IT Environment dependencies. • Scheme Interpretations • We’re probably OK here unless we run into a case where two national interpretations are in conflict and where there is no international interpretation. • Rationale Section • We will need to carefully consider their recommendations on writing rationale statements.

19. Basic Robustness Environment Analysis • Conventions • Make edits to the PPs to align with their recommendations. • Are there interpretations we need to explicitly reference? • Glossary • We should align with their definitions; however, we may have to include additional explanatory text. • Degree of Compliance • We will specify Demonstrable Conformance. • FAU_GEN.1-NIAP-0407 (Audit Data Generation) • Align our audit record requirements with NIAP-0407 • Ask how this would work in evaluations in other countries. – Peter C.

20. Basic Robustness Environment Analysis • FAU_SEL.1-NIAP-0407 (Audit Event Selection) • Same as #16 • FAU_STG.1-NIAP-0429 (Audit Event Storage) • Same as #16 • FAU_STG.3 (Action in case of possible audit Data Loss) • FAU_STG.3 is not used in the current PPs. • FAU_STG.NIAP-0414 (Audit Event Storage) • Should we mandate that the administrator have this authority in the PP? If not in the PP but in a specific ST, it should be done as per the NIAP interpretation. • We keep the PP as is (for now.)

21. Basic Robustness Environment Analysis • FIPS 140-2 • Include in PP but see if there is a way to allow PP compliance for products that aren’t meant for US Gov’t sale. (Peter will talk with DAPS and/or NIAP.) • FDP_ACF (Access Control Function) • See #16 • FDP_IFF.1 and .2 (Information Flow Control Functions) • .1 – See #16 (.1.1 wording confusing in assignment) • .2 – Not Applicable • FIA_AFL.1 (Authentication Failures) • We can align with this one.

22. Basic Robustness Environment Analysis • FIA_USB.1 (User-Subject Binding) • Is this an error? This says for Medium Robustness profiles when it means Basic Robustness. See table 7 in document. • Currently, we don’t invoke FIA_USB.1 because HCDs don’t typically support users acting on behalf of other users. • This is recommendation, not a requirement. • FPT_TST_EXP.1.1 (TSF Self Test) • This is a recommendation, not a requirement. • We’ll keep what we have because of the range of products our PP will support. Conclusion: There is work to be done to bring our PPs into alignment with these guidelines but it doesn’t appear to be insurmountable. The PP team and the editor will work on bring the PPs into alignment with these instructions.

23. Reorganization of Document From Smithson note of May 11, 2005, a suggestion was made to reorganize the document: • document intro • scope, purpose • how to use this document • structure, by manufacturers, by users , block diagrams of the document structure • Definitions / glossary / acronyms • protection profiles (very general) • Overview of Common Criteria • introduction to protection profiles (not the actual protection profiles themselves) • Forward reference to actual PPs • intro to HCDs • what they are, do • how they are similar/different from other IT devices • why they make good targets if insecure • environments • scope of environments that we're considering in this spec • advice on choosing the correct environmental guidance • environment #1 • definition, assumptions, examples/diagram, cautions/disclaimers • environment #2...#N • (as above) • Summary • assets • overview of assets • asset type #1 • definition, discussion, importance in the different environments • asset type #2...#N • (as above) • summary Formerly Section 1 NEW Formerly Section 1 Move from PPs to Section 1 plus enhancements

24. Reorganization of Document (cont.) • threats and mitigation • overview of threats • threat vector model, top level categories -- related to assets • general recommendations for manufacturers • out-of-box, etc., best practices that aren't covered earlier • general recommendations for end-users / IT departments • IT environment, etc., best practices that aren't covered earlier • specific threats and mitigation • threat #1 • detailed description • importance in each environment / coverage in protection profile(s) • recommendations for manufacturers • recommendations for customers • threat #2...#N • (as above) • Specific overview of the PPs in the annexes • annexes • Protection Profiles • Annex A: HS • Annex B: Enterprise • Annex C: SoHo • Annex D: Public • (perhaps some materials extracted from Best Practices would be better as annexes? e.g. discussion on selecting passwords) • Threat cross reference (by asset / by access) • references (from section 1 and 3) • bibliography (from section 1 and 3) Formerly Section 3 Formerly Section 2

25. Document Review • Review Comments on Draft per Excel Chart • Section 1 • Section 2 • Section 3 • High Security PP Results contained in: P2600-comments-database-May 2005.xls

26. Document Review: Enterprise PP • Review Draft – Not done, insufficient time • Any comments submitted? • ?

27. Document Review: SoHo PP • Review Draft – Not done, insufficient time • Any comments submitted? • ?

28. Other PPs • What is schedule? • Public PP: Jean Claude • No news

29. Other • Threat Analysis – discussion summary • Why would the value of a user document vary in a person’s risk assessment? • FIPS-199 contains useful definitions • Develop more detail directions and guidelines for performing the assessment • Re-run the assessment with the new information from this meeting and the guidelines • Involve more people in doing the assessments. • Look at the results and propose which threats should be removed or added to PPs. • Owner – Brian Smithson (will propose a timeline)

30. Other • Difference between HS and Enterprise environments. • Enterprise - Generally medium value assets • Can be physically medium to large in geographic area and in number of devices on the network. • Areas within the enterprise that have high value assets (perhaps due to legislated mandates) can be treated as High Security islands within the enterprise. • New enterprise examples • Cable TV Company – production printing of bills • Large advertising agency • Big box retailer • Delete: DA Office, Health Claims • Update HS examples • Delete “Top Secret” from Military Research Lab • Move Financial/Stock Broker and SS Office to HS environments. • Is there anything else that needs to be reviewed?

31. Reminder: Managing the Process Going Forward • Going forward we must manage the discussion and changes to the document. • For the following components of the standard, we will have no “random” discussions. All proposed changes MUST be on the e-mail reflector at least one week before the meeting including specific changes requested. • Sections 1 through 3, High Security Profile • Enterprise Profile – Not at this time. • Additions sections will be added to this list as they mature.

32. Project Schedule • The PAR included estimates of the end-points of the schedule: • Sponsor Ballot: June 2005 Sept 2005 • Submission to RevCom: Feb 2006 • What schedule should we expect now?

33. Next Meeting Details • July 11-12 – Cupertino, California @ Apple (with PWG) • Where: Apple Campus 1 Infinite Loop Cupertino, CA 95014 Building: _____, Room: _____ • Some Nearby Hotels: • Cupertino Inn(408) 996-7700, http://www.cupertinoinn.com/10889 N de Anza Blvd, Cupertino, CA 95014 • Marriott Courtyard (408) 252-9100, http://marriott.com/property/propertypage/SJCCU10605 North Wolfe Rd, Cupertino, CA 95014 • Cypress Hotel (408) 253-8900, http://www.thecypresshotel.com/ 10050 S de Anza Blvd, Cupertino, CA 95014

34. Action Items for July • ?

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