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.