So does this go before or after the requirment for opening a
port in the firewall...........:)
I don't agree with putting security criteria for implementations in a
Are we then going to put requirements on access to the output bin or the
panel of the device...??
We should certianly describe how the "pipe" can be secured but anything
about the security of the device should be in left to a security
I wonder how many https servers also accept simultaneous http
"McDonald, Ira" <firstname.lastname@example.org>@pwg.org on 01/28/2004 05:57:36 PM
Sent by: email@example.com
This topic came up during today's ongoing review of the
IPPFAX Protocol spec. It affects implementing IPPFAX/1.0
along with any other protocol on the same device or server.
Given the basic network security principal:
"The actual security level of a given service instance
depends on the _least_ secure protocol interface of
_any_ service on the same host system."
I propose that the IPPFAX/1.0 Protocol spec should say:
"A host system with an enabled IPPFAX/1.0 Receiver (as
defined in this document) MUST NOT enable any other
protocol configured with less security than IPPFAX/1.0
(i.e., less secure than TLS/1.0 [RFC2246] with required
server authentication and optional client authentication).
Note: Equivalent security to IPPFAX/1.0 can be achieved
by the object security defined in S/MIME [RFC2633], or
by the stream security defined in Secure Shell Protocol
[draft-ietf-secsh-architecture-15.txt - in IESG queue],
or by many other strong security mechanisms. But such
protocols as SNMPv1 [RFC1157] or IPP/1.1 without TLS/1.0
MUST NOT be enabled on a host system with a currently
enabled IPPFAX/1.0 Receiver."
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
This archive was generated by hypermail 2b29 : Thu Jan 29 2004 - 09:08:13 EST