Subject: IPP> on the use of SSL3 framing and SASL

From: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 1997 17:22:55 -0500

Chances are that IESG won't allow a standards track RFC to incorporate
the SSL3 protocol.  It will have to reference the TLS protocol.
Fortuantely, the TLS spec is essentally finished - the TLS WG has
finished its internal Last Call and would appear to be ready to send
the spec back to IESG.  So I don't expect that referencing the TLS
spec would delay adoption of IPP as a standard.

Also, while it's technically feasible to always use TLS framing with
IPP, it seems like it would be far better to define a SASL negotiation
framework for HTTP, which could then negotiate TLS.  SASL is already a
Proposed Standard RFC, and is being retro-fitted into a number of
existing apps protocols.

Keith

---

From: Ron Bergman <[email-masked]>
Date: Fri, 7 Nov 1997 15:23:44 -0800 (Pacific Standard Time)

Keith,

Could you give me a hint as what RFC describes SASL?  A search on SASL or
security or secure does not result in a match.

	Thanks,
	Ron Bergman

---

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 7 Nov 1997 15:22:09 PST

Keith,

We will never get this project finished if we keep getting new or changed
security requirements from the Area Directors every week. This has already
held us up for an extra couple of months.

Can you confirm whether SASL now allows a user to negotiate that they do
NOT want to use security features as an option, otherwise I expect that we
do not want to touch it. An assumption in earlier discussions was that TLS
allowed for this, but apparently not any more after the latest IESG
intervention.

Can you PLEASE consider our project as a user of the IETF security
standards and when security comes up next in the IESG, in your role as our
project advisor, make it clear that we want to have one option which is
simply NO SECURITY (beyond RFC 2069, which we mandate support for in our
protocol specification).

Thanks,

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: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 1997 19:42:51 -0500

> Could you give me a hint as what RFC describes SASL?

RFC 2222

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Nov 1997 20:02:05 -0500

> held us up for an extra couple of months.

The alternative, in this case, might be to get the project "finished"
but have it going in a different direction from other HTTP-based
protocols.  If the IPP working group wants to explicitly decide to
do that, that might be just fine, but I believe it's worth considering
how to keep things coordinated.

> NOT want to use security features as an option. 

Of course it does.  Both parties have to agree on the level of
security used.  Otherwise nobody would use it.

With SASL, if a client doesn't want to use security, it simply
doesn't issue the AUTH command.  (Of course, the server could then
deny access to any other commands with an insufficient authentication
error.)

> simply NO SECURITY (beyond RFC 2069, which we mandate support for in our

This is fine with me, and as far as I know, it will be fine with
the rest of IESG.  As far as I'm concerned, SASL and/or TLS can 
be optional for an implementation.  

Keith

---

From: Randy Turner <[email-masked]>
Date: Fri, 07 Nov 1997 22:40:40 -0800

By the way, I could be easily convinced to modify my
proposal instead to use SASL/TLS, as long as we
specify only one way to do IPP security, one that meets
our charter requirements. I would also like to
see us do our best to avoid secure and non-secure URIs for
IPP services.

Randy