1. The reason why we needed an AUTH parameter is to indicate to the http
channel (layer) that we are using a security protocol like SSL or TLS or DAA
or BAA or IPSEC or anything. 443 is used for SSL, 80 for DAA and 631 for no
security. We could also run DAA on port 631. There may be other protocols
for other ports. Explicitly mentioning them would ease the burden of upward
migration to include newer protocols or running protocols on different
ports.
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 at hp-roseville-om3.om.hp.com
[mailto:PETER_E_MELLQUIST at hp-roseville-om3.om.hp.com]
Sent: Friday, September 18, 1998 12:43 PM
To: ipp at 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