2. AUTH can be changed to SECURITY or SECURITY-PROTOCOL. That was chosen for
convenience.
3. ACLs or capabilities can be used for this purpose. This is part of
version 2 or later for ipp.
Daniel.
-----Original Message-----
From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
[mailto:PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com]
Sent: Friday, September 18, 1998 12:43 PM
To: ipp@pwg.org
Subject: IPP> Comments / Issues on Security Proposal
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