Carl-Uno
>Return-Path: <moore@cs.utk.edu>
>X-Uri: http://www.cs.utk.edu/~moore/
>From: Keith Moore <moore@cs.utk.edu>
>To: Carl-Uno Manros <cmanros@cp10.es.xerox.com>
>Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, szilles@adobe.com,
> rdebry@us.ibm.com, manros@cp10.es.xerox.com, don@lexmark.com
>Subject: Re: Security in IPP
>Date: Tue, 23 Sep 1997 14:27:36 PDT
>Sender: moore@cs.utk.edu
>
>> The IPP WG is now getting close to finishing the IPP specifications, and we
>> plan to go out with a last call for the WG in early October. We have been
>> trying to come up with a suitable compromise regarding security, which
>> takes some real life conditions into account. As recommended to Keith in a
>> mail note from Roger deBry, this is the kind of security statements that we
>> would like to make:
>>
>> 1) All IPP clients and IPP servers SHALL support the security features
>> specified in RFC 2069 (which provides client authentication to protect
>> printers against spamming or other misuse). This would be sufficient for
>> some scenarios.
>
>This is fine.
>
>> 2) If IPP clients and IPP servers need added security (mutual
>> authentication and/or encryption) they SHOULD support TLS. However, we
>> would like to add a statement to the effect that use of SSL3 should be
>> considered conformant until TLS is commonly available and deployed (as
>> specified in Annex E of the TLS specification for interworking between
>> SSL3/TLS).
>
>Hmmm.
>
>It's okay to mention SSL3, and even suggest that it might be used,
>but you should not call it "conformant"... rather, state that use
>of IPP+SSL3 is outside the scope of the standard.
>
>If there are details that need to be specified re: use of IPP
>with SSL3 so that such implementations will interoperate,
>you might state those in an appendix or in a separate
>(informational or experimental) RFC.
>
>(In general I'm concerned about client configuration issues
>w.r.t. this kind of use of TLS -- a TLS 1.0 client has to
>know in advance which credentials are required by a particular
>server -- the client has no way of finding out which CAs the
>server trusts, nor which TLS ciphersuites it uses. It's
>not that these issues cannot be dealt with in the context
>of IPP -- it's just more information that must be pre-configured
>in the client before it can print -- but unless these things are
>carefully specified, I fear that IPP clients and servers will
>not interoperate in secure mode.)
>
>The document should state that standardization of IPP+TLS is
>expected in the near future, and that clients or servers using SSL3
>which are developed in advance of IPP+TLS standardization might
>not be interoperable with IPP+TLS standards-conforming servers or
>clients.
>
>FWIW, to me it looks like the TLS WG may be moving again.
>
>Keith
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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@cp10.es.xerox.com