> 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