[glue-wg] Security considerations

[Paul Millar]

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 at ogf.org
>
> > [mailto:glue-wg-bounces at 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.