Michael,
One more comment below.
Carl-Uno
> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Friday, April 23, 1999 9:20 AM
> To: Carl-Uno Manros
> Cc: Paul Moore; 'Keith Moore'; IETF-IPP
> Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>---snip, snip----
> My only concern with the latest meeting notes is that the language
> seems to indicate the TLS support is required in all clients:
>> After hearing Keith's response, Hugo Parra made a new proposal:
> Clients must support TLS + Basic AND Digest; Printers must support
> TLS + Basic OR Digest. The group acknowledged that this is a
> modification to the previous agreement, but consensus was reached
> to adopt Hugo's new proposal. A more formal proposal describing
> the details will be distributed for review.
>> Clearly this would severely limit the number of IPP clients that could
> hope to claim IPP/1.1 compliance. I would suggest the following
> wording instead:
>> Servers are REQUIRED to implement "TLS + Basic" OR Digest.
>> Clients are REQUIRED to implement Digest. If the client supports
> TLS then it is also REQUIRED to support "TLS + Basic".
>> I can appreciate the IETF's desire to promote security in all of the
> standards it endorses, but we also need to balance that against
> practicality. Digest support is currently available with most server
> products (in most cases using the less secure RFC 2069 draft) and
> doesn't involve licensing or other restrictions on its use. Because
> of the nature of TLS, vendors (and customers!) face licensing fees and
> government-imposed restrictions/regulations of varying degrees.
>> The main thing that I don't want to see is fragmentation in the IPP
> "community". IMHO, requiring TLS support in clients is one way to
> ensure fragmentation.
>
The reasons for the two security alternatives on the server side was because
some implementations are already supporting SSL3 and for those guys it is
probably easier to upgrade to TLS, while other have nothing and want to
limit
their costs and footprint for security, in which case the "Digest" solution
is easier.
The trouble with your proposal is that if we keep the OR for the server,
then a "Digest" only clients will not be able to use the security features
of a "TLS + Basic" server and we don't have the interoperability which will
prevent fragmentation.
Yet another alternative would be for everybody who supports "TLS + Basic" in
the server to also support "Digest", but then we are back to where we
started
again...
We did spend the best part of a day last week in New Orleans to come up with
the latest suggestion, and I still think that it is the best compromise we
can make, trying to meet the different requirements.
Carl-Uno
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com