The following text contains all of the possible boilerplate type text that
we might use to explain security in general. This was compiled by Daniel
Manchala at erox from various sources on security in netwoks. It probably
contains more than what we want to include in IPP right now, but we should
discuss what to cross out and what to keep.
----
Security Services=20
The following is a list of terms that is defined for the Security
Infrastructure Working Group. It has only basic terms, plus those terms
with controversial or multiple meanings. For a more complete glossary of
security terms, see Network Security by Charlie Kaufmann, Radia Perlman &
Mike Speciner; Computer Security Basics by Deborah Russell & G. T. Gabgemi
Sr; or The Directory, CCITT Recommendations of the X.500 Series, 89/267=20
Basic Concepts
1 AAA: Overall term for security. The three A's are generally taken to be
Authentication, Authorization, and Auditing although it may mean
Authentication, Authorization & Accounting in some contexts.=20
2 Authentication: The process of reliably determining the identity of a
communicating party. There are three classic ways of authenticating
oneself: something you know, something you have and something you are. The
two entities involved in the communication could use the following two ways
to authenticate themselves.
=B7 Single entity authentication. Only one of the entities is authenticated
by the other. It could be either data origin or data recipient=
authentication.
=B7 Mutual authentication. Both the parties authenticate each other.
3 Authorization: The granting of rights to a user, program or process.
Permission to access a resource. It is used to protect a resource from
unauthorized use. This can be achieved by the use of access control lists
(ACL) or capabilities.
4 Auditing: Keep a record of events that might have some significance, such
as when access to resources occurred. To record independently and later
examine system activity. Audit data is generally used for security concerns
(e.g. intrusion detection and consistency checks).=20
5 Accounting: Keep a record of events that might have some significance,
such as when access to resources occurred, who accessed it, what was
accessed and for how long. Accounting data is generally used for commercial
concerns (e.g. billing and charges).=20
Security Service Attributes
1. Anonymity: The ability to communicate so that the other principal can't
find out the identity of the sender.=20
2. Integrity: Keeping information from corruption or unauthorized
modification either maliciously or accidentally. Integrity protects against
forgery or tampering.=20
3. Non-Repudiation: There is proof who sent a message that a recipient can
show to a third party and the third party can independently verify the
source.=20
4. Privacy (Confidentiality): Protection from the unauthorized disclosure
of data.=20
Encryption Concepts
1. Encryption: To scramble information so that only someone knowing the
appropriate secret can obtain the original information.=20
2. Public Key: Dual key (RSA/PGP style) cryptography. Uses two different
keys, either one for encryption and the other for decryption. Also called a
asymmetric cryptography.=20
3. Secret Key: Single key cryptography. Also called symmetric cryptography.=
=20
4. Session Key: A short lived Secret Key used by two principals for the
purpose of secure communications between them.=20
Authorization Concepts
ACL: Access Control List. A list of the subjects authorized to access that
object. The list usally indicates what type of access is allowed for each
user.=20
Groups: A named set of users, created for convenience in stating
authorization policy.=20
Roles: A specific function a principal plays with respect to another
principal. Examples include a system administrator of a individual computer
system, and a bank teller at a particular bank. If a principal has multiple
functions with respect to another principal, it has multiple roles (e.g. A
person can have both the bank teller role and the customer role at a
particular bank).=20
Capability: An identifier that specifies an object and the access rights
for the subject who possess the capability. See also "Certificate / Ticket
/ Token"=20
=20
Proxy Agent: A principal that has been authorized to work on the behalf of
another.=20
Proxy: A token that grants the rights of a principal to another.=20
Restricted Proxy: A token that grants the rights of a principal to another
while placing restrictions on the privileges granted.=20
Certificate / Ticket / Token: Different names for a object used to grant
privileges. While these terms have individual meanings in specific contexts
(Kerberos generates tickets, physical objects are tokens), there is no
general agreement on how they differ. We will use Certificate / Ticket /
Token largely interchangeably. Capability & Proxy are related terms, but
with narrower focus.=20
CRL: Certificate Revocation List. A list of revoked certificates.=20
Miscellaneous
Denial of Service: An action that prevents a system or its resources from
functioning efficiently and reliably.
The following table describes how some of the available security protocols
would support the security services that we are looking for:
S.No Services HTTP/1.1 SSL (V2) SSL (V3) LDAP
1. Authentication
=B7 single entity Yes Yes Yes --
=B7 mutual No No Yes --
2. Authorization
=B7 ACL -- -- -- --
. Capabilities -- -- -- Yes
=20
3. Non-repudiation No No No --
4. Integrity No Yes Yes --
5. Confidentiality No Yes Yes --
6. Administration
=B7 Certificate Mgmt. -- -- -- -- Yes
-- means "not applicable"
----
The following text was produced after some discussion between Dainel and
Carl-Uno. This is just intended as a problem description at this stage.
We need to discuss which of these scenarios we want to support and how.
We started looking at in which order the different protocols are invoked
etc. and came up with a number of possible cases:
=B7 The IPP server enforces security on all IPP clients that wants to talk t=
o
it, by switching from IPP to e.g. SSL if an IPP client tries to invoke any
operation over IPP. If the client cannot respond, that is the end of the
story.
=B7 The IPP client wants to enforce security and starts off by invoking SSL
before trying to invoke any IPP operations. If the server cannot respond,
that is the end of the story.
=B7 The IPP client may want to first find out if the IPP server supports a
particular security protocol, such as SSL version 3. It then first invokes
a Get Printer Attributes operation to get the information, or might get it
over Directory, if the IPP server would refuse to answer. The IPP client
should get the information back that the server supports security protocols
A,B and C. The IPP client then chooses one, provided it has capability to
use at least one of them and the communication goes along.
=B7 The IPP server may want to enforce security, but rather then just
refusing the connection it returns an error in which information about
available security protocols are given as error reasons.
=B7 A server or client may support both secure and non-secure printing. In
this case it should be possible to inform each other about the possible
options and allow each end to select what they want to do.
Taking these different possible scenarios together, it starts looking like
we might need either some kind of negotiation feature at the beginning of
an IPP session in cases where either the IPP client or the IPP server end
wants to use any of the security features, or we well need to define a
fixed behavior pattern and possible restrictions for how server and clients
should behave to invoke the security services.
In either case, it looks like at a minimum, we will need to define a
Printer attribute (multi-valued) that can give information about security
protocols supported by the IPP server, and which can be found both as
directory and as Printer atttributes.
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: manros at cp10.es.xerox.com