[glue-wg] Security considerations

[Paul Millar]

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 at 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.