Subject: IPP> New protocol document & Security issues

From: John Wenn <[email-masked]>
Date: Wed, 28 May 1997 05:15:34 PDT

There are a couple of security issues involved in the latest protocol 
document.  They cover sections 5.5, 5.7, 6.x, 6.y & 7.

The issues are basically in two areas.

(1) You should be using HTTP Digest Authentication (rfc2069), not HTTP Basic 
Authentication.  Basic authentication provides zero security (unencrypted 
username and passwords are sent over the wire).  Digest authentication 
provides moderate security.  So reference Digest authentication is section 
5.5.  The headers used for Digest authentication are the same (Authorization, 
Proxy-Authorization, WWW-Authenticate, Proxy-Authenticate), but they have 
different values.  Since the paper doesn't go into details, the other sections 
should be fine as they are.

(2) Not all authentication / authorization is done via HTTP.  For example, the 
connection may be made using SSL.  In that case, SSL provides the 
authentication needed.  While the sections are generally good about saying 
HTTP authentication is used when needed, somewhere the fact that other 
security mechanisms are used should be made explicit.

And, of course, section 7 (security considerations) needs to be rewritten, but 
the security group should do that.

/John

---

From: Randy Turner <[email-masked]>
Date: Wed, 28 May 1997 11:40:31 -0700

> should be fine as they are.

We talked about basic authentication in Memphis and we decided that
low-end IPP
servers could use this because it is simple.  We really only need two
levels of security,
simple and advanced, for interoperability's sake. The simple case would
be basic auth.,
which alot of vendors are already supporting (username and password) in
their products.
The advanced case would be something like SSL or TLS/SSL, something that
meets
all of the security requirements discussed in past meetings. In my
opinion, just two
security models is all we need.

> security mechanisms are used should be made explicit.

Within the context of the document (basic HTTP authentication) simple
security
is all within HTTP. We are defining a mapping document for IPP over HTTP
so I
have to list HTTP-specific mechanisms for IPP security. These are
implementation
conformance requirments. However, the overall "Security Considerations"
section should
be fleshed out with all of the information that we think is necessary
for security between
IPP clients and servers, whether they are actually in the IPP protocol
mapping
itself, or, at a layer beneath the IPP/HTTP layer (such as through an
API like SSL or
TLS/SSL or other).

Randy

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 28 May 1997 12:44:03 PDT

Randy,

a couple of comments to your latest comments below.

>security models is all we need.

When you say that we discussed this in Memphis, I think that you might
have a different view of what was meant with "simple security".

You can certainly use the basic stuff that is in your document,
but if used, that will fall into the category "no security" as seen by the 
SEC subgroup. What we mean by "simple security" is the stuff in RFC 2069,
and "avanced security" would be things like TSL (equal to SSL3).  If you
are unhappy with this, I suggest you join in the SEC subfroup discussions. 
The SEC subgroup will soon have a new draft for review. 

Carl-Uno

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: "Scott Lawrence" <[email-masked]>
Date: Wed, 28 May 1997 17:05:28 -0400

>>>>> "RT" == Randy Turner <[email-masked]> writes:

RT> We talked about basic authentication in Memphis and we decided
RT> that low-end IPP servers could use this because it is simple.  We
RT> really only need two levels of security, simple and advanced, for
RT> interoperability's sake. The simple case would be basic auth.,
RT> which alot of vendors are already supporting (username and
RT> password) in their products.

>>>>> "CM" == Carl-Uno Manros <[email-masked]> writes:

CM> You can certainly use the basic stuff that is in your document,
CM> but if used, that will fall into the category "no security" as seen by the
CM> SEC subgroup.

  Seconding Carl-Uno;

  The HTTP Basic Authentication scheme is no authentication at all,
  and I suspect will be treated as such by IESG reviewers.  To quote
  from the report on a recent meeting of the IAB
  <http://www.iab.org/iab/secrets.html>, in a section titled "To be
  Killed: Plaintext Passwords":

    "Any protocol that relies on the transmission of unencrypted
     passwords is terminally broken."

  If the IPP security mapping document mentions the Basic
  authentication scheme it at all, it should be to explicitly disallow
  it as a means of providing a security service.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/