We appreciate the initial effort in writing the White Paper, but think that
the subject requires considerable further discussion.=20
Carl-Uno
---Comments on IPP Security White Paper
General: =20 Things not covered so far:
- How users "discover" printers is not addressed, but important. Security may require that users not see printers for which they have no access when locating printers on the network. Also, directory information about a printer should include the security level required by the printer.
- Key management is an important issue, not covered here.
- We would like to see scenarios for each of the suggested security levels in order to understand them better.
- Scenarios where the document to be printed is fetched by the "printer" from a repository on behalf of the user is not covered.
Other general comments: =09 - Use of SSL only gives authentication, but authorization will have to be provided by the printer and some discussion of generic authorization levels will be useful for each scenario. Does level 4 and 5 also assume functionality from level 3 to cover this?
- SSL assumes mandatory server authentication, but only optional client authentication. Scenarios where printers must be authenticated at the client are not covered here.
-------Start text from the White Paper:
As we add security to the IPP model we need to keep in mind the added complexity that security can bring to the system as well as the overhead in terms of network traffic and end-user response time. Running IPP on top of a Secure Sockets (SSL) session provides for message privacy, message integrity, and mutual authentication, but at some added cost. Therefore we might want to consider a model which allows several levels of security, at various cost points, to be configured by the system administrator (from the White Paper):
1) No security: Anyone can submit jobs to the printer. No user ID or password is required. All data transmissions are in the clear. This is the cheapest solution and might well fit into environments not connected to the external Internet where anyone within the environment can freely access any printer.
2) Access Control - no password: The Printer object has an associated Access Control List (ACL), but no password is required to print. All data is sent in the clear. Users are not authenticated.
3) Access Control - password required: The Printer object has an associated ACL which has passwords for each authorized user. Users are not= authenticated.
4) Authenticated access control: The Printer object has an associated ACL. Users identify themselves by sending their public key certificates to the Printer object. Data is still sent in the clear. This scheme would probably be the right level for controlled access within the Intranet. It is still fairly lightweight, but guarantees that only authenticated users can access a given printer or printers.
5) SSL access control: Any communication with the printer is done over an SSL session. Public key certificates are required for both users and Printers. This method would be required where a Printer is made visible outside of the firewall. An SSL session is established, both client and Printer are authenticated, and all data is encrypted before being sent. Message integrity is checked for each transmission.
-------End text from the White Paper:
Let=92s investigate each of these situations and see how it might impact the IPP specification.
- Level 1) No Security
In this simple case, the IPP model is used as described. If <job-originator> is required for some reason, for example, to print on a header sheet, the Printer would have to ask for it or it would have to be supplied with the Print request. If the Printer can prompt for <job-originator> we need to define the mechanics of how this works. For this simple case, I=92d suggest that it always be sent in the Print request.
- Level 2) Access Control - No Password
We believe this case is not different from level 1) from a security-level perspective - names can easily be faked - if simply stating names is adequate for securing rights associated with that name, this has the same level of security as level 1) with the exception of requiring an extra attribute.
This case would be much like the previous one, except that <job-originator> is now a required attribute. The printer must either prompt the user for it, or it must be supplied in the Print request. <job-originator> is checked against valid names in the Printers Access Control List (ACL).=20
ACLs usually contain more information than just user names, such as user rights to access services. Perhaps these rights might be grouped under logical printers - still information regarding which logical printer the user is allowed use is important, as well as, what is the user type (such as normal-user, operator, and administrator). Also if there are printers the users are not allowed to use, these might be identified here.
In this simple case, we suggest that <job-originator> always be sent in the Print request.
- Level 3) Access Control - Password Required
This case builds on the previous one. The Printer either prompts for both <job-originator> and <job-originator-password> (a new attribute), or they are included in the Print request. <job-originator> and <job-originator-password> are both checked against valid names and passwords in the Printer=92s Access Control List. Again, we would suggest that these flow with the original Print request else we have to define some mechanism to prompt for them.
- Level 4) Authenticated Access Control
What is the user scenario that requires level 4) but not level 5)?
Authenticated access control requires the use of public key certificates. One way to achieve this would be for the original Print request to carry the job-originator=92s public key certificate along with a digitally signed message to verify the identity of the requester.=20
The Printer needs to now authenticate the job-originator=92s certificate,= but this exchange is outside the scope of this protocol. The printer now has enough information to validate that the request really came from the named job-originator. =20 If we can do this exchange differently for different printers, as is proposed, how can we assume the same level of security in each case?
If the job-originator name is in the Printer=92s Access Control List then= the Print request is honored.
Another, simpler approach to this would assume that the Printer=92s ACL actually contained the public key for each authorized user. The flow could then be something like:
Print request ---------------------------------------------- <job-originator : john doe> <digital signature : xxxxxxxxxxx>
This appraoch may not be secure enough even for intranets: an intruder can capture the digital signature, and send it along with the job originator and submit any job. ("man-in-middle" attack, combined with "replay" attack)
Since the printer already has john doe=92s public key, it can decrypt the message hash, compare it, and validate that it came from john doe. (anyone else sending it would have to have john doe=92s private key). This would not be an unreasonable approach in a corporate intranet. Getting user=92s public keys into the ACL is outside of the scope of this specification.
- Level 5) SSL Controlled Access
When a print service provider accepts print requests from outside of the firewall, it is critical that mutual authentication and full message privacy and integrity be provided. If I send a print job to something advertised as a "Kinko=92s Print shop", I=92d like to be sure that that is really where= the print job is going. Likewise, for billing purposes, the print provider must guarantee that the requester is who he says he is. This level of security seems to require full use of an SSL session. In this case the client initiates a secure session with the print provider. Secure browsers use a well know port for an SSL session, we would have to do the same for IPP. During the initiation of the SSL session, the client and print provider agree on a protocol version, exchange public key certificates, select encryption algorithms, and use public key encryption algorithms to generate shared secrets. Now the IPP protocol runs over a secure session. Clearly, this is a lot of overhead, but seems to be required in this particular environment.=20
Authorization levels is assumed to be part of this, but is not covered by= SSL. Non-repudiation (proof of origin, proof of receipt, proof of submission and proof of delivery) is not covered, but may not be required by the user scenarios under consideration.
Recommendation
Based on the above, we would like to recommend the addition of two= attributes =B7 <job-originator-password> =B7 <job-originator-signature>
The client would always send <job-originator> and would send <job-originator-password> or <job-originator-signature> based on the type of security established in the system when it was configured. SSL would only be used in Internet configurations.
We question whether levels 2) and 4) are really needed and meaningful, unless some convincing scenarios can be presented that actually require= them.
-----
Carl-Uno Manros Xerox Corporation 701 S. Aviation Blvd. M/S: ESAE-231 El Segundo, CA 90245, USA E-mail: manros@cp10.es.xerox.com