Joe,
Some feedback since I won't be able to call in:
- Currently the headings read "IDS Security Model" and the title says "IDS Imaging Device Security Model (IDS-Model)". Can we update both to read "Imaging Device Security Model (IDS-Model)" for consistency?
- You can use RFC 2818 as a reference for HTTPS (in 2.2 terminology, probably in other places too)
- (editorial) In section 2.2, all of the terminology uses a semicolon to separate the term from the definition, but I think we decided we should be using a full colon instead...
- Suggested text for 3.1:
3.1 Rationale for the Imaging Device Security Model
Given the following existing specifications and the need for a standard method of defining, describing, and enforcing security for Imaging Devices, the Imaging Device Security Model should:
1. Use existing protocols and schema to support definition, description, and enforcement of desired security policies,
2. Define new Semantic Model elements and values to support identification of users, printers, jobs, and documents,
3. Define new Semantic Model elements and values to support delegated resource access,
4. Provide example policies based on existing printing and imaging service specifications, and
5. Provide recommendations for Imaging Device Security policies based on accepted security best practices.
[references to RFC 2911, MFD Common, 2600, and IDS Log?]
- Section 3.2.x: "Internet" is always capitalized.
- Section 3.3: Include loss of connection with authentication service, directory services, etc?
- Section 3.4: Out of scope should include definition of new authentication methods and definition of new security policy definition languages/formats.
- Suggested text for 3.5:
3.5 Design Requirements
The design requirements for the Imaging Device Security Model specification are:
1. Define new Semantic Model elements and values to support identification of users, printers, jobs, and documents,
2. Define new Semantic Model elements and values to support delegated resource access,
3. Define example policies based on existing printing and imaging service specifications,
4. Provide recommendations for Imaging Device Security policies based on accepted security best practices, and
5. Support authentication, authorization, and access control using existing protocols and schema.
- Global: Review usage of lowercased conformance words.
- 4.1.1:
- Would it help to talk about user roles before here? Or at least provide a forward reference?
- "In general, the access control policies SHOULD observe ..."?
- Item 1: "... SHOULD only be accessible ..."?
- Item 2: Status data is regularly directly by the corresponding service (so we can't say "these data MUST never be modified". Perhaps say something along the lines that "Status elements including ... are maintained by the Imaging Device and MUST NOT be directly writable outside the corresponding Imaging Device services. Certain Imaging Device service operations MAY indirectly change status elements, such as the Job state in response to a CancelJob operation."
- Item 2: Data retention requirements/policies should be a separate item, "History data MAY be deleted by the Imaging Device after a configured or regulatory maximum retention period in order to reduce storage space usage."
- Item 3: Drop "operations" from "Job-oriented operations" (you already said operations). "although" here is confusing, maybe "Any operation affecting an existing Job or Document is restricted ...". "The local site policy MAY cause ..."
- Item 4: Do we want to define a "Defacto Administrator/Operator" role for services like Copy? Or "Console User"? Or something like that to convey that an unauthenticated person has expanded access because they are at the physical device?
- Throughout this document there is reference to an "enterprise authentication framework", among other names. Since we also want this for Cloud-based solutions, can we use/define AAA Framework (as used in IPPSIX and I think Cloud Model) as the common authentication framework for the Client and Imaging Device services?
- (IPP/SM) Scan, IPPSIX, and Cloud Model expose the End User's Document content. We should talk about that content only being available to authorized users (generally job/document owner, administrator, operator, and proxies)
- I don't think we want to say that an Imaging Service cannot encrypt or sign documents. Rather, we might say that it is out of scope for this specification (so list it in section 3.3 as well) to define how an Imaging Service would do it. Clearly there are cases where an Imaging Service might encrypt document data prior to storing it in a less-trusted document repository (or transport).
- 4.1.4: Are we actually requiring cryptography here - seems like the conformance requirement here isn't aimed in the right direction? Seems like providing recommendations is appropriate here rather than requiring conformance to something that is not specified?
- 4.2: I would not list social security number as a means of identification for printing, since that is expressly NOT allowed by the US Government. Also, a lot of this seems like information that is already defined in other (referenced) specifications. Better perhaps to define the elements/values that IDS Model uses than to provide an (incomplete) tutorial on authentication and identification.
- Global: References to published specifications should be of the form "[PWG510x.y]".
- 4.3: This sounds a bit like tutorial + advertising. I would simplify it: "In order to support health assurance on controlled networks, Imaging Devices SHOULD support the Imaging Device Security Health Attributes [PWG5110.1] and corresponding Network Access Control protocol bindings such as Network Access Protocol (NAP) [PWG5110.2] and Trusted Network Connection (TNC) [IDS-TNC]."
- 4.4: We should be referencing 5110.3 (IDS Common Log), which in turn references the various syslog specs and provides security considerations for transport and so forth.
- 4.5: Instead of simply listing what P2600.x says, I would make these recommendations, e.g., "Imaging Devices SHOULD use a standard network time server ...", etc.
- 5: First you say you will be recommending something. Then you say there are several standards for this. Then you recomment PWG standards use the following general specifications. How about just "The following sections provide the default Semantic Model access control policies using standard, widely-deployed languages."
- 5.1: It is well-suited for PWG standards. How about for users of our standards? Also, I think we need to actually provide a complete example policy based on the current MFD Common Model operations.
- 5.2: Need to see an actual policy.
- For 5.1 and 5.2, I think excerpts are sufficient in the text, with a durable link to the full policy file.
- 6.1.x: What about Client as an actor? For cloud I definitely see the need to authenticate/identify the Proxy (which for purposes of the Security Model is a special Client...), and "pairing" is a common security step these days to authenticate not only the User but the device/software. I see this as distinct from Device, just as we have Service separately.
- 6.1.1: What about Imaging System?
- 6.1.2: Clients connect to Services, not Users.
- 6.2.x: Add Subscription (in IPP, someday in SM?), Service, and System/Device (the latter for policies on the System Control Service/System Object)
- 6.3.1: Add Proxy: A user who is authorized to access as a proxy for a device or service, fetching and accepting Jobs, fetching, accepting, or uploading Documents, and updating device or service state and capabilities.
- 6.4.3/Figure 2: Add ClientSecurity, SubscriptionSecurity
- 7.1: Needs intro to table, add securityClientAuthorization/IdentificationError
On Apr 11, 2014, at 3:59 PM, Murdock, Joe <jmurdock at sharplabs.com> wrote:
> I alo didn’t see this email come through the IDS reflector last night, so I’m resending it
>>> From: Murdock, Joe
> Sent: Thursday, April 10, 2014 4:46 PM
> To: ids at pwg.org> Subject: [IDS] Updated IDS Model document posted
>> I’ve posted an update to the IDS model document to address the comments from the last review. We will review this in next week’s conference call.
>> Sorry, but due to massive confusion on the part of Microsoft Word, there is not a redlined version available
>>ftp://ftp.pwg.org/home/pwg/ids/wd/wd-ids-model10-20140410.pdf>ftp://ftp.pwg.org/home/pwg/ids/wd/wd-ids-model10-20140410.docx>> Joe
>> -------------------------------------------------------------------------------
> Joe Murdock
> Principal Engineer and Researcher
> Chair IEEE/ISTO Printer Working Group Imaging Device Security
> Sharp Labs of America
> 5750 NW Pacific Rim Blvd
> Camas, WA 98607
> (360) 817-7542
>jmurdock at sharplabs.com>> _______________________________________________
> ids mailing list
>ids at pwg.org>https://www.pwg.org/mailman/listinfo/ids
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20140414/cb8ee9e7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ids/attachments/20140414/cb8ee9e7/attachment-0001.p7s>