This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf6288?nav=1&selectedTab=comments at Sun, 06 Nov 2022 11:34:03 GMT SourceForge : artf6288: GLUE 2.0 Spec - Security Considerations

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: GLUE     Trackers > GLUE 2.0 Specification > View Artifact
Artifact artf6288 : GLUE 2.0 Spec - Security Considerations
Tracker: GLUE 2.0 Specification
Title: GLUE 2.0 Spec - Security Considerations
Description:
to add content in the section
Submitted By: Sergio Andreozzi
Submitted On: 11/17/2008 8:27 AM EST
Last Modified: 12/03/2008 9:28 AM EST
Closed: 12/03/2008 9:28 AM EST

Status / Comments Change Log Associations Attachments  
Status  
Status:* Closed
Category: * specification
Priority: * 4
Assigned To: * Paul Millar
Reported in Release: *
Fixed in Release: *
Comments
Sergio Andreozzi: 12/03/2008 9:28 AM EST
  Comment:
this version to be added

. 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.

The GLUE conceptual model 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 of 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 information is
included within the GLUE conceptual model.  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 conceptual model 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 conceptual 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 any 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 such that the agents' ability to modify information is
controlled and appropriate.


9.4.6 Man-in-the-middle.

For a system implementing the GLUE conceptual model, 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.



--- GLUE-2.0-security-0.4	2008-11-21 10:33:51.000000000 +0100
+++ GLUE-2.0-security-0.5	2008-11-21 14:17:25.000000000 +0100
@@ -1,8 +1,9 @@
-This version 0.4:
+This version 0.5:
   v0.1 initial version
   v0.2 with changes from Maarten.
   v0.3 with changes from Stephen.
   v0.4 with changes from Maarten.
+  v0.5 fix typo, spotted by Maarten.
 
 
 
@@ -200,8 +201,8 @@
 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' ability to modify information is controlled and
-appropriate.
+limits such that the agents' ability to modify information is
+controlled and appropriate.
 
 
 9.4.6 Man-in-the-middle.
  Action: Update
Closed set to 12/03/2008
Status changed from Open to Closed
Sergio Andreozzi: 11/17/2008 8:27 AM EST
  Comment:
This version 0.2:
  v0.1 initial version
  v0.2 with changes from Maarten.

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 system conforming to 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 is the information may depend on many
factors, including the software agents that publish data and the
transport used to propagate information.

The software used to provide an information system 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

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

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 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 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.  GLUE conceptual model 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 GLUE conceptual
model.  A replay attack would revert part (possible all) of the
information in the conceptual model to some previous state as seen by
some (possible all) end users.

A replay attack may result in disrupted service.  If security
attributes, such as authorization, are embedded within 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 system 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 to modify information is key to providing accurate
information.  However, concrete data models and software
implementation should limit agents so their ability to modify
information is limited and appropriate.


9.4.6 Man-in-the-middle.

Man-in-the-middle attacks may allow arbitrary modification of data
within the GLUE conceptual model.  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 GLUE conceptual model should understand the risk from
lack of information.  Appropriate measures should be taken to ensure
the systems continue to run to the extent possible.
  Action: Update
Sergio Andreozzi: 11/17/2008 8:27 AM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf6288?nav=1&selectedTab=comments at Sun, 06 Nov 2022 11:34:03 GMT