> 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.
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.
> (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.
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
> And, of course, section 7 (security considerations) needs to be
> rewritten, but
> the security group should do that.
>
> /John