Peter,
The only thing wrong with your proposal is that Keith Moore speaking for the
IESG has now repeatedly told us that they would not accept any
implementation that cannot do client authentication. The IESG has gradually
increased their requirements for security and what people might have got
away with in earlier protocols does not apply today.
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: Sunday, April 25, 1999 9:49 PM
> To: paulmo at microsoft.com> Cc: ipp at pwg.org> Subject: Re: IPP> Security in 1.1
>>> 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?
>