I am happy to see a concrete proposal on security and IPP. Reviewing the
proposal by Wenn and Manchala, I have a few questions / issues:
1)Protocols like SSL or TLS already have there own port numbers for running
HTTP over them. For example HTTP-S (HTTP over SSL) uses port 443. Therefore if
we are running IPP on port 443 it is implied that we are using SSL. There is no
need to specify this in the security parameters since it can be nothing other
than SSL. For TLS port switching, the protocol is already captured in the
"Upgrade: TLS/1.0" parameter. Why have the "AUTH" parameter?
2) parameters := "AUTH=" secure-protocol *["," secure-protocol]
secure-protocol := "TLS" | "SSL3" | "DAA"
If you still insist on having this parameter, why is the field called "AUTH".
"AUTH" can mean authentication or authorization? Neither of these is what I
believe you mean. Furthermore, most security protocols can have the following
options: no-authentication, no-privacy; authentication and no-privacy or
authentication and privacy. Why not just call it "SECURITY". "AUTH" is
misleading.
3) I did not find anywhere in the document the concept of authorization a.k.a.
access control. Perhaps this can be found in another draft? Can one IPP user
destroy jobs of another user? Without access control this would be possible. A
complete security scheme should have different levels of access allowing
administrators to see and manage all jobs while normal users would only be able
to see and manage their own jobs. Has this concept been discussed? Protocols
such as SSL or TLS do not directly address this security requirement. Further
work to devise ACL tables or user groups might be required. Should IPP include
an access control object whereby access can be defined and managed?
Peter Mellquist
Hewlett-Packard Company