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.