Hi all, As promised, here's a few words on security, following from RFC-3552's suggestions: Cheers, Paul --- 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 a 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 outwith 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 Unauhorized 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 procedure 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) 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 implementing software 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 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 implementing software should ensure that 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 implementing software 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 whenever possible.