I have drafted some thoughts on IPP security. I'd appreciate comments ......
=====================================================================
IPP Security 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:
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.
Let*,s investigate each of these situations and see how it might impact the IPP
specification.
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*,d suggest that it always be sent in
the Print request.
Access Control - No Password
----------------------------
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. In this
simple case, I*,d suggest that
<job-originator> always be sent in the Print request.
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*,s Access
Control List. Again, I*,d suggest that these flow with the original Print
request else we have to define
some mechanism to prompt for them.
Authenticated Access Control
----------------------------
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*,s public key
certificate along with a digitally
signed message to verify the identity of the requester. The Printer needs to
now authenticate the job-
originator*,s 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-origina
tor. If the job-originator
name is in the Printer*,s Access Control List then the Print request is honored.
Another, simpler approach to this would assume that the Printer*,s 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>
Since the printer already has john doe*,s 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*,s private key).
This would not be an unreasonable approach in a corporate intranet. Getting
user*,s public keys into the
ACL is outside of the scope of this specification.
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*,s Print shop", I*,d 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.
Recommendation
--------------
Based on the above, I*,d like to recommend the addition of two attributes
<job-originator-password>
<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 if the system were configured that way, typically in open
internet configurations.