Subject: IPP> Re: Security in IPP

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 23 Sep 1997 16:36:34 PDT

Please see this exchange between myself and Keith on the subject of 
IPP security.  I suggest we add this subject to our phone conference
on Wednesday September 24.

Carl-Uno

>Return-Path: <[email-masked]>
>X-Uri: http://www.cs.utk.edu/~moore/
>From: Keith Moore <[email-masked]>
>To: Carl-Uno Manros <[email-masked]>
>Cc: [email-masked], [email-masked], [email-masked],
>        [email-masked], [email-masked], [email-masked]
>Subject: Re: Security in IPP 
>Date: Tue, 23 Sep 1997 14:27:36 PDT
>Sender: [email-masked]
>
>> 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: [email-masked]