Hi all,
I've tried to update the security section, based on Stephen's comments. I've
also tidied up the language a little (removed a double-usage of limit, that
sort of thing).
Stephen, could you check the changes are OK?
I've included v0.3 in-line below and attached the diffs against v0.2.
Cheers,
Paul.
---
This version 0.3:
v0.1 initial version
v0.2 with changes from Maarten.
v0.3 with changes from Stephen.
9. Security Considerations
This section considers security implications when using the GLUE 2.0
conceptual model. It follows the advice given in RFC-3552.
As the conceptual model of GLUE 2.0 provides limited scope for
embedding security information many of these concerns listed here are
delegated to the concrete data models and to the underlying software
implementations. Nonetheless, some points are independent of which
concrete data model is employed so some discussion is appropriate.
When deploying an information service conforming to the GLUE 2.0
conceptual model, consideration should be given to the points
discussed below.
9.1 Communication security
The GLUE conceptual model is independent of how information is stored
and how that information is exchanged between agents. Because of
this, concern for communication security is largely delegated to the
underlying concrete data model and software implementations.
9.1.1 Confidentiality.
GLUE information schema contains information that may be personal or
confidential in nature. Contact details and indications of end-user
activity may fall into this category.
Conforming implementations should identify which components of the
data should be considered confidential and appropriate precautions
should be in place to safeguard against disclosure to unintended
audiences.
9.1.2 Data integrity.
The information within GLUE has many potential uses, from operational
to accounting. How accurate the information is may depend on many
factors, including the integrity software agents that publish data and
the transport used to propagate information.
The software used to provide an information service may cache GLUE
information. If so, these caches provide additional points where data
integrity may be compromised.
9.1.3 Peer Entity authentication.
No explicit description of the agents that publish GLUE information is
included within the GLUE schema. This prevents authentication
information from being included within the abstract model.
In general, support for peer-entity authentication is delegated to the
concrete data model or the underpinning software. In many cases the
agents will act on behalf of some AdminDomain; if so, elements of peer
entity authentication (e.g., public/private key-pairs) may be included
using the described schema extension mechanisms provided issues with
data integrity are understood.
9.2 Non-repudiation
The GLUE conceptual model contains no explicit description of the
publishing agents that provide GLUE information. This prevents
explicitly support for non-repudiation. In many cases a set of
publishing agents will provide information for Services in some
AdminDomain. If so, then it is the AdminDomain that asserts the
non-repudiation of the data the publishing agents provide.
Non-repudiation may require information from whoever asserts the
non-repudiation of the data; for example, a cryptographic certificate
of some AdminDomain. If the publishing agent is identified with an
AdminDomain then this information may be included using the schema
extension mechanisms of the AdminDomain (via OtherInfo or Extension).
It is also possible for this information to be included in fields
specific to the concrete data model or it may be provided outside of
the GLUE conceptual model.
In addition, information may be published with corresponding
non-repudiation information, such as a cryptographic signature.
Signatures may be included using schema extensions (OtherInfo or
Extension) or may be included in fields specific to the concrete data
model.
9.3 System security
The GLUE conceptual model intended use is to provide an abstract view
of a grid system. There are many processes that may make use of this
information, each may depend on the GLUE conceptual model to undertake
work.
9.3.1 Unauthorized usage
The GLUE conceptual model has no explicit description of end-users of
the schema information and no explicit description of authorized
usage. In general, is assumed that any authorization controls for
access to the GLUE information is provided by specific concrete
bindings and software implementation.
It may be possible to identify a UserDomain with those agents
authorised to use GLUE information and embed authorization information
using described schema extension mechanisms, provided issues with data
integrity are understood.
9.3.2 Inappropriate Usage
The GLUE conceptual model provides no mechanism for describing
appropriate usage and does not include a data-processing model, so
providing a description of inappropriate usage is considered
out-of-scope.
Individual grids may describe what they consider appropriate usage of
GLUE information and implement appropriate procedures to ensure this
policy is enacted.
9.4 Specific attacks
RFC-3552 describes several specific attacks that must be considered.
These are detailed below.
9.4.1 Eavesdropping
Some information described in the GLUE schema may be sensitive in
nature; this may include contact details and descriptions of user
activity. Appropriate care should be taken to prevent unintended
access or disclosure to an unintended audience.
9.4.2 Replay
Grid operations may depend on information provided in the GLUE
conceptual model.
If a system implementing the GLUE 2.0 conceptual model is susceptible
to a replay attack then it is possible for part (possibly all) of the
information in the conceptial model to be reverted to some previous
state as seen by some (possible all) end users. Please note that this
is a specific case of the more general modification attack.
A replay attack may result in disrupted service. If security
attributes, such as authorization, are embedded within the GLUE
conceptual model then a replay attack may result in inappropriate
access to data.
Underlying concrete models and software implementations should prevent
replay attacks.
9.4.3 Message insertion
The ability to insert information is key to providing accurate
information. However, inserting incorrect information may have a
detrimental effect to the running systems; for example, there are
attributes in the conceptual model that accept multiple values. If
incorrect values are included, the systems may suffer.
Many aspects of GLUE provide service discovery. Inserting false
information would allow unauthorised services to publish their
presence and attract activity. This may be used as a basis for
further attacks.
Underlying concrete models and software implementations should ensure
that an agent's ability to insert information is limited and
appropriate.
9.4.4 Deletion
The ability to delete information from an information service could
interfere with normal operations; for example, if Services are removed
then activity that would use those services may be affected; if
AdminDomains are removed then normal operation procedures may be
impossible; if security components are removed (such as X509
certificates) then facilities such as non-repudiation may become
ineffectual.
Underlying concrete models and implementing software should ensure
that any ability of an agent to delete information is limited and
appropriate.
9.4.5 Modification
The ability for an agent to modify information stored in an
information service is key to providing accurate information.
However, concrete data models and software implementation should place
limits on agents so the agent's ability to modify information is
controlled and appropriate.
9.4.6 Man-in-the-middle.
For a system implementing the GLUE 2.0 information mode, a successful
man-in-the-middle attack may lead to arbitrary modification of data
(see 9.4.5). It may also allow deleting existing data (see 9.4.4) or
adding additional data (see 9.4.3). This may have severe influence on
the systems based on GLUE information.
Underlying concrete models and implementing software should understand
the risk from man-in-the-middle attacks and provide appropriate
security against them.
9.4.7 Denial of service attacks
A Denial of Service attack is one that attempts to prevent normal
operation of systems. Perhaps, the most obvious is to prevent or
corrupt the flow of information.
Systems using the GLUE conceptual model should understand the
consequences of a partial or complete lack of information.
Appropriate measures should be taken to ensure the systems continue to
run to the extent possible.
