Item Subject: IPP> Security in 1.1
I agree,
The typical approach with adding security to protocols within the IETF
has been a less restrictive approach. That is, rather then require all
implementations to implement authentication, a multi-level approach is
more flexible. For example, consider the following multiple levels:
No-auth / No-privicy:
No authentication and no privacy. Lowest level really does nothing
more than IPP 1.0 although it may be negotiated for.
Auth / No-privacy:
Authentication only and no privacy. Second level allows for
authentication but no encryption of data.
Auth / Privacy:
Authentication and privacy. Highest level allows for authentication
and encryption.
Note, in all cases the authentication and privacy algorithms may be
different based on what SSL or TLS can handle.
Peter Mellquist
Hewlett-Packard Company
______________________________ Reply Separator _________________________________
Subject: IPP> Security in 1.1
Author: Non-HP-paulmo (paulmo at microsoft.com) at HP-Roseville,shargw4
Date: 4/21/99 3:30 PM
I have just read this in Harry's email. This is from Keith Moore:
"the IPP spec must require that all combinations of conforming client
and server implementations be able to provide authentication which
does not expose a password to eavesdroppers, and which protects the
printer resource against unauthorized use."
This is going too far (nothing to do with TLS vs SSL vs digest, etc.). It is
simply not practical nor desirable to REQUIRE all printers to support
authentication. (Note that I have no axe to grind here in terms of my
product, I support authentication and encryption in both client and server).
I do agree that we must say what security mechanisms are used IF a client or
server want to be protected. But we should not REQUIRE that protection is
supported (a client may simply choose not to print to that device).
Saying that it only takes a small amount of code is missing the point - how
do I enter valid user names and passwords into the network card of a
printer?