Peter,
A few comments on your contribution below.
Carl-Uno
> -----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:
We already have a lot of text on IPP security in our other
drafts on IPP Model & Semantics and IPP Encoding & Transport.
The new text is only a delta to fill in additional information
about features needed in addition, when we introduce the
IPP URL Scheme.
> 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?
You are right about SSL, but wrong about TLS. For historical
reasons HTTP over SSL3 has it's own port number, but that
has been banned by the IETF Area Directors for TLS and future
IETF standards as eating up the number of available port #s
too quickly. Hence, HTTP over TLS will use the same port #
as HTTP, but in the case of IPP over HTTP that will be port 631,
which is the default port for IPP.
> 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.
I think you are right on this one, it might be better to
call it something more neutral like "SECURITY".
> 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?
Authorization is currently not covered in IPP (or in any other IETF
application standard that I know about). It is currently assumed that
Authorization is done with some non-standard means, based on the
Authentication information. One or two of the Security WGs are
currently starting work on the general subject of Authorization,
but I expect that it will be years before we get something that can
be used in IETF application standards. ACLs in LDAP servers might be one
approach, but LDAP itself is still struggling with getting security
features in place.
Having said this, there are a number of statements in the other
IPP documents about access control, e.g. preventing users from
canceling jobs that do not belong to them, except when the domain
has a policy allowing administrators or operators to do that.
> Peter Mellquist
> Hewlett-Packard Company
Thanks for your comments,
Carl-Uno