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.
Hi Paul,
As promised, here's a few words on security, following from RFC-3552's suggestions:
Nice job! Some suggestions inline.
9. Security Considerations
[...]
When deploying a information system conforming to GLUE 2.0 conceptual | ^ | an
[...]
9.2 Non-repudiation
[...] specific to the concrete data model or it may be provided outwith of | ^^^^^^^ | outside
Nobody outside (!) Scotland uses that word... :-)
the GLUE conceptual model.
[...]
9.3.2 Inappropriate Usage
[...]
Individual grids may describe what they consider appropriate usage of GLUE information and implement appropriate procedure to ensure this | ^^^^^^^^^ | procedures
policy is enacted.
[...]
9.4.2 Replay
Grid operations may depend on information provided in GLUE conceptual model. A replay attack would revert part (possible all) information | ^ | of the
[...]
Underlying concrete models and implementing software should prevent | ^^^^^^^^^^^^^^^^^^^^^ | software implementations
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 | ^ | that
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 | ^^^^^^^^^^^^^^^^^^^^^ | software implementations
that agent's ability to insert information is limited and appropriate. | ^ | an
[...]
9.4.5 Modification
The ability to modify information is key to providing accurate information. However, concrete data models and implementing software | ^^^^^^^^^^^^^^^^^^^^^ | software implementations
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 | ^^^^^^^^^^^^^^^^^^^^^ | software implementations
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. | ^^^^^^^^ | to the extent
Thanks, Maarten
On Tuesday 04 November 2008 20:00:04 Maarten Litmaath wrote:
As promised, here's a few words on security, following from RFC-3552's suggestions:
Nice job! Some suggestions inline.
Thanks for the comments. I've incorporated them all in the new version below.
9.2 Non-repudiation [...] specific to the concrete data model or it may be provided outwith of | ^^^^^^^ | outside
Nobody outside (!) Scotland uses that word... :-)
(I try to sneak it in every so often ;-) Cheers, Paul. --- 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.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: When deploying an information system conforming to GLUE 2.0 conceptual model
Just getting back to this ... you use this kind of phrasing in various places, where I would be inclined to say "the GLUE" rather than just "GLUE".
The information within GLUE has many potential uses, from operational to accounting. How accurate is the information may depend on many
"the information is"
9.4.2 Replay
My feeling is that replay per se isn't relevant to GLUE because there is no kind of transaction involved - a replay would just be another case of modification.
9.4.6 Man-in-the-middle.
Similarly I don't think this is a specific risk because the information flow is one-way, again this is just another way to modify the information. Stephen -- Scanned by iCritical.
Hi Stephen, Thanks for the comments and suggestions. Maarten, shall I apply these changes and send you a revised version? On Wednesday 19 November 2008 14:33:20 Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: When deploying an information system conforming to GLUE 2.0 conceptual model
Just getting back to this ... you use this kind of phrasing in various places, where I would be inclined to say "the GLUE" rather than just "GLUE".
I agree: "the GLUE" sounds better than "GLUE".
The information within GLUE has many potential uses, from operational to accounting. How accurate is the information may depend on many
"the information is"
You're right: "the information is" is better.
9.4.2 Replay
My feeling is that replay per se isn't relevant to GLUE because there is no kind of transaction involved - a replay would just be another case of modification.
[BTW, please check RFC-3552; it says we MUST talk about certain attacks, like replay] Hmmm, yes and no. As an information model, Glue has little to do with many aspects of security, a lot of that comes from the implementation. That said, there's some common ways that the underlying implementation might fail (reply, denial-of-service, MitM, etc). These may have slightly different impacts on the Glue info model, so warrent discussing separately. Here's an example: Supposing someone implements an Info Service using Glue where each message is signed using X509 certificates. This could then prevent a (non-authorised) third person from injecting arbitrary new data or arbitrarily rewriting existing data. However, suppose there's a flaw in the system's implementation: these X509-signed messages do not include some extra information to make them "single use" (e.g., there's no time-stamp or message counter). If Eve records these messages, she may be able to inject it at a later date. Although she couldn't undertake a "modification" attack, the system is open to a "replay" attack. So, I think this one should stay in.
9.4.6 Man-in-the-middle.
Similarly I don't think this is a specific risk because the information flow is one-way, again this is just another way to modify the information.
I'm not so fussed about this one, but please bear in mind that RFC-3552 says we MUST talk about MitM attacks. The OGF says we should use RFC-3552 as a guideline (iirc), so we're not bound to RFC-3552's regulations. However, the RFC seems to be very well written, so I'd be inclined to follow it. Anyway, this section isn't very long and doesn't say anything too controversial, so I'd be inclined to keep this one, too, but if you feel it's a waste of space we can also remove it. What do other people feel? Cheers, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
[BTW, please check RFC-3552; it says we MUST talk about certain attacks, like replay]
OK, but the "talking about" may presumably just be a statement that it doesn't apply.
If Eve records these messages, she may be able to inject it at a later date. Although she couldn't undertake a "modification" attack, the system is open to a "replay" attack.
OK, that's a reasonable point, but perhaps you should say that explicitly. Usually replay attacks mean that you are capturing one side of a transaction and replaying it later to the other side, and that kind of thing doesn't seem relevant to GLUE.
Anyway, this section isn't very long and doesn't say anything too controversial, so I'd be inclined to keep this one, too, but if you feel it's a waste of space we can also remove it.
You can leave the section in, but say that it's a special case of modification. Again the usual meaning of mitm is that you sit in the middle of a transaction, e.g. a fake web site that looks like your bank, passes your keystrokes on to the real site and passes its reponses back to you. Stephen -- Scanned by iCritical.
Hi Stephen, I'll try to make appropriate changes and circulate a v0.3. On Thursday 20 November 2008 12:25:10 Burke, S (Stephen) wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
[BTW, please check RFC-3552; it says we MUST talk about certain attacks, like replay]
OK, but the "talking about" may presumably just be a statement that it doesn't apply.
Yup.
If Eve records these messages, she may be able to inject it at a later date. Although she couldn't undertake a "modification" attack, the system is open to a "replay" attack.
OK, that's a reasonable point, but perhaps you should say that explicitly.
I'll try to add something appropriate.
Usually replay attacks mean that you are capturing one side of a transaction and replaying it later to the other side, and that kind of thing doesn't seem relevant to GLUE.
Anyway, this section isn't very long and doesn't say anything too controversial, so I'd be inclined to keep this one, too, but if you feel it's a waste of space we can also remove it.
You can leave the section in, but say that it's a special case of modification.
Fair enough, I'll try to add something.
Again the usual meaning of mitm is that you sit in the middle of a transaction [...]
What's confusing me is your use of "transaction" when talking about replay and MitM attacks. AFAIK, neither are specific to transaction-based interaction and may also apply to non-transaction-based interactions; for example, see: http://en.wikipedia.org/wiki/Man-in-the-middle_attack http://en.wikipedia.org/wiki/Replay_attack I couldn't find any mention of transactions on those pages (not that that's definitive, of course! :)
, e.g. a fake web site that looks like your bank, passes your keystrokes on to the real site and passes its reponses back to you.
Aye, that's a MitM attack, but I wouldn't classify it as transaction-based. For me, a transaction implies some kind of indivisible compound of multiple operations so they either all succeed (at the same time) or all "state" is "rolled back" as if none of the operations have taken place: http://en.wikipedia.org/wiki/Transaction_processing ... but perhaps we may have different definitions. HTH, Paul.
Hi Paul,
Maarten, shall I apply these changes and send you a revised version?
Why me in particular?
[BTW, please check RFC-3552; it says we MUST talk about certain attacks, like replay]
I think it is good to keep the text as complete as it is now (with the few agreed changes), so that we can forestall any security discussions.
participants (3)
-
Burke, S (Stephen) -
Maarten Litmaath -
Paul Millar