Keith,
thanks for the constructive advice that you have given us. I think that I
might have interpreted your requirements as more strict than you actually
intended to.
As for scenarios where no security is needed:
1) Public printers that provide a similar service to fax machines today
(with the calculated risk that you might get spammed).
2) Clients and servers that both sit behind the same firewall.
Again thanks for your advice.
Carl-Uno
At 06:14 PM 9/3/97 PDT, Keith Moore wrote:
>> I want to verify with you what I interpreted to be new additional security
>> requirements from our Munich discussions:
>>>> 1) You are expecting that every new IPP session starts up with a security
>> negotiation.
>>>> 2) You are expecting that every IPP Client and Printer has the capability
>> to support more than the security defined by RFCs 2068 and 2069, e.g.
>> features corresponding to SSL2 in TLS.
>>We probably haven't fully articulated the requirements but, no, I don't
>think the requirements are so severe. Rather, I'd say:
>>>1) the security considerations section should analyze known attcks
> and possible countermeasures
>>2) if the protocol needs authentication (as IPP almost certainly does)
> you need to provide better authentication than plain-text passwords.
>>And offhand, I see several ways in which the requirement could be met:
>>+ Since IPP is using HTTP/1.1, I would expect that digest access
> authentication would pass the "no plain-text passwords" test.
> This would meet the minimum authentication requirement, but shared
> secrets don't scale very well. Nor can this be used to provide
> confidentiality. Still, for a small printer that can't handle
> large volumes anyway (and this wouldn't be expected to serve a
> large user community), this might be just fine.
>>+ IPP could be specified to *always* use TLS (and always on a port
> assigned to IPP - no separate IPP/TLS port), but allow use of
> the anonymous and/or NULL encryption ciphersuites for those cases
> where authentication and/or privacy were not required.
>>+ IPP could also use SASL along with TLS by defining a STARTTLS method
> for HTTP when used with IPP, and an AUTH EXTERNAL-like mechanism for
> HTTP. This would allow TLS to be negotiated on an open connection.
>>>HTTP's security is of course a real mess, given that HTTP is itself
>a lot of hacks glued together. And as you observe, SSL/TLS (which
>was designed with a very narrow view of HTTP in mind) doesn't really
>provide the flexibility needed to mutually authenticate clients
>and printers and effectively administer those credentials.
>>My advice would be for IPP to specify TLS 1.0 for now, but to also
>make recommendations about additional features/flexibility needed
>in TLS 1.1.
>>>> We have started looking into this and are running into the following
issues:
>>>> 1) We have identified several scenarios where security is not needed and
>> where the overhead of security negotiation and mandatory support for
>> unnecessary security features is a useless extra burden.
>>Here's a question: do you expect that people should be able to submit
>a print job without some prior arrangement -- say to set up a print
>queue on the client machine, or to install a "driver", or to exchange
>security credentials between client and IPP server?
>>If no, then the "security negotiation" can be part of this "prior
>arrangement" -- e.g. the authentication method (though perhaps not
>the credentials) can be incorporated into the IPP URL that's given
>to the client.
>>But if you want to be able to print with no prior arrangements,
>then you need to be able to negotiate different authentication
>and/or privacy algorithms.
>>My guess is that you do expect to make prior arrangements before
>actually printing, so this isn't a problem. This is a contrast
>to the normal web browser / http server situation, where the necessity
>to make prior arrangements (i.e. to know whether to use http: or
>https:) means that users have to make decisions that they don't
>understand... and discourages use of security even where
>it is needed.
>>>> 2) TLS is not yet really stable and furthermore does not provide a lot of
>> security negotiation features.
>>Agreed. But it's probably the best we have for now.
>>> 3) SASL could potentially offer a better negotiation package, but does not
>> work well with TLS; actually according to recent discussions on the
>> security DLs, it seems that they are almost totally incompatible. SASL on
>> its own does not provide what we need.
>>Last I knew, this had all been figured out. Use a STARTTLS method
>to push a TLS layer on top of an existing connection; HTTP could
>certainly do this. Then either use a special HTTP request header to
>indicate that the server should use authentication credentials from
>the TLS negotiation, or use some other kind of HTTP authentication
>header (basic or digest) over the TLS channel. (If the encryption
>were good enough, even basic authentication would be sufficient,
>but good luck getting the US goverment to grant permission to export it)
>>I'm not sure which security DLs you're referring to, so I don't know
>whether they've identified new issues that would prevent this from
>working.
>>> 4) It is also not clear how TLS and HTTP can be made to work together.
>>Details need to be worked out, but I don't see any insurmountable
>barriers.
>>> 5) In the Munich IPP meeting we stated that we thought this was really a
>> problem for HTTP, and that we could live with most any solution that worked
>> for HTTP. We are still of that opinion.
>>Part of the problem is that HTTP and IPP really have different security
needs.
>Authenticating clients and printers is very different than authenticating
>clients and web servers, at least for the scenarios for which SSL/TLS
>was desgined. Web browsers that use SSL typically do not authenticate the
>client at all; this would not be acceptable for a printer. Web servers
>that use SSL authenticate themselves to clients by having their keys signed
>by one of a few well-known CAs, but this doesn't scale very well to mass
>market printers. etc.
>>> We are still digging around to see if we can come up with some half baked
>> solution that might approximately meet your requirements, but we recent the
>> idea that we have to develop a separate and special security solution for
>> IPP just because the appropriate security standardization projects are
>> still working on their specs.
>>That's certainly not the intention, and we haven't done this with
>other protocols. The only requirement that has been imposed recently,
>is that you can't authenticate with plain text passwords.
>(believe me, we don't want APPS groups trying to design security
protocols...)
>>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 at cp10.es.xerox.com