I am forwarding to you a series of comments made by our local security team.
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 at cp10.es.xerox.com