Subject: IPP> SEC - IPP Security Requirements

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 3 Sep 1997 16:45:07 PDT

Keith and Harald,

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 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.

2) TLS is not yet really stable and furthermore does not provide a lot of
security negotiation features.

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.

4) It is also not clear how TLS and HTTP can be made to work together.

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.

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.

I am looking for some constructive advice from you as Area Directors.

Is our only option to wait until the security WGs have sorted themselves
out, or are you prepared to relax the requirements?  We have been prepared
to let IPP use existing implemented (proprietary) security features and
products for the Internet as an intermediate step, until the IETF security
groups can provide us with standardized and implemented security solutions.

It seems to us that the overall IETF requirement that application standards
include security features before they are fully specified, stable and
implemented is putting up an artificial barrier to application area
projects being able to finish their specifications. 

Regards,

Carl-Uno

for the IPP WG

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]

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Sep 1997 21:14:12 -0400

> 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.  

> 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.

> security negotiation features.

Agreed.  But it's probably the best we have for now.

> 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.

> 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.

> 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

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 3 Sep 1997 18:56:50 PDT

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

Carl-Uno Manros

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Sep 1997 22:43:14 -0400

> might have interpreted your requirements as more strict than you actually

I'm sorry if I wasn't clear in Munich.  
(I botched several things in that meeting -- must have been a bad day for me!)

For the most part, it's up to the IPP working group to determine the
minimum security needs for the IPP protocol -- and then to document
the level of protection provided, threats, etc. in the security section.

The group will need to establish some minimum security level -- what 
minimum degree of authentication and/or confidentiality should be 
required for all clients and/or servers (the two could be different), 
to ensure that all clients and servers can interoperate "out of the 
box", once they are given the necessary credentials, and with a 
degree of security that is appropriate for *most* (not just some)
uses of the protocol.  (The group could argue that the minimum security
level is "none" for both clients and servers, but it would have to 
convince IESG that this is adequate for most installations....)

Note that a implementation requiremnt is not a requirement of any
particular installation -- any installation can disable authentication
and/or require stronger authentication than the default, according
to that installation's policy. 

Keith

---

From: [email-masked]
Date: Thu, 04 Sep 1997 20:26:28 +0200

Keith is doing fine.....

two things:

1) IPP has to ANALYZE risks of using IPP on the open Internet (NOT behind
   firewalls or in "spammable" environments)

   IPP must then DEFINE how a reasonable number of these risks can be defended
   against using security mechanisms, and REQUIRE that valid IPP 
implementations
   implement at least a minimum set of these

   The USER of an IPP device can then decide to use or not to use those
   security mechanisms.

2) I'd like you to tell me which security lists are discussing SASL; it
   seems that the list set up to discuss SASL is either totally dead or
   I've fallen off it. We need to know!

Thanks for your help!

                     Harald A