IPP> IPP-Security comments and clarifications from the 39th IETF.

IPP> IPP-Security comments and clarifications from the 39th IETF.

IPP> IPP-Security comments and clarifications from the 39th IETF.

Daniel W. Manchala manchala at cp10.es.xerox.com
Wed Sep 3 14:01:09 EDT 1997


Recently some comments were brought up at the 39th IETF meeting held in Munich 
related to security. Some of the questions, and my clarifications are written 
below. 




Q: Why not start a secure session and then drop to an insecure level.


A: You could have two separate sessions - first secure - then drop the session 
- and then start a new insecure session. You cannot drop to an insecure level  
in one session. However, once a secure session has been started, it is not 
advisable to drop to an insecure level or session. First, it is usually not a 
security practice. Second, security protocols do not allow such a transition. 
For example, such a thing does not exist in SSL, nor can Netscape visualize 
having such a feature in SSL in the near future. Third, customers or clients 
who have security would continue to make use of that session rather than 
switch to an insecure session immediately following a secure session. Fourth, 
you may find certain customers or clients not to  have security features 
(i.e., the relevent certificates, browsers or software) on their system and 
hence may want to start an insecure session first and then discover that they 
require certificates to continue with the print request. This essentially 
means that they may want to start off in an insecure inquistive mode, but move 
over to a secure exchange later on. Finally, the very purpose of having a 
secure session is lost if you want to drop to an insecure level later on.


This may give rise to other questions:
  a. Don't you think that SSL encrypts data, and this is time consuming? Users 
may want to switch to a lower level just for that reason. The answer is 
simple, there is nothing you can do about it in the current version of SSL. If 
you do not want to encrypt, the best you can do is use the fetch-and-print 
feature where you can fetch a document without encryption and print it off. 
This is the print-by-reference feature. Then, this is how we need to design 
this.
  b. Then how about starting an insecure session and then moving over to a 
secure session? The answer is again simple, one cannot do the transition in a 
single step. First, one will discover that the print request requires a secure 
session by looking at the HTTP 403 error message. Then, one should use https 
or provide the required and necessary certificates (in case you are already 
using https) to make a secure session. I demo'ed this to you on Monday.
  c. So, what do you think? should I use an LDAP server to know if a printer 
can communicate securely? No. It is not necessary to use LDAP to discover the 
printer's secure capabilities. As explained above, the server to which the 
printer is tied has the capability of notifying the client that it needs to 
use a secure SSL exchange. 


Q: I am not sure if a client can connect to a https port when it uses a http 
URL.
A: Again, I showed this to you. The client will get an error message. Ah - now 
we need IPP to interpret this message - Is the client using http instead of 
https or is it just that the client does not have the right certificates or is 
due to something else? The error message is - "Access Forbidden Secure Channel 
Required - This ... requires a browser that supports the configured encryption 
options". By looking at this error message, one is not sure if the encryption 
options are correctly used (as one sets it up in netscape browser) or if it is 
 just the wrong use of http instead of https. This is something that HTTP or 
HTTP-NG needs to look into, and probably pass on a different error for 
different things. This is not IPP's task. I do remember that we need to 
participate in HTTP-NG efforts for security too.


Q: Why don't we start with SSL2 and then transition to SSL3?
A: Remember, TLS supports servers that can talk either SSL2 or SSL3. This 
transition should be transparent though it should be verified. However, we do 
not have an implementation of TLS available at this time. It is hard to check 
this with current implementations of SSL2 and SSL3 separately. We probably 
need changes to SSL client software.




Dan.



More information about the Ipp mailing list