IPP> Comments / Issues on Security Proposal

IPP> Comments / Issues on Security Proposal

IPP> Comments / Issues on Security Proposal

Manchala, Daniel manchala at cp10.es.xerox.com
Fri Sep 18 18:11:42 EDT 1998


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



More information about the Ipp mailing list